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ABSTRACT 

Synchronization code is necessary to control shared access of an abstract data object in 
a parallel-processing environment. This thesis explores an approach in which a 
synchronization property can be specified in a high-level nonprocedural language, and an 
implementation for the specified property can be synthesized algorithmically. A problem 
specification language is introduced in which synchronization properties can be expressed in 
a structured but natural manner. A method is then presented for synthesizing an 
implementation. An intermediate form, called a solution specification, is first derived, 
representing an abstract solution to the problem. The derivation of the solution 
specification accomplishes the transformation of the specification from nonprocedural to 
procedural form. The solution specification can be translated directly into a source 
language synchronization mechanism, such as a monitor. 

Specifications for common synchronization properties, such as the readers-writers and 
bounded buffer problems, are expressed in the problem specification language. 
Corresponding implementations are then synthesized for these problems. In addition, the 
derived solution specification can be used in analyzing the soundness of the original 
problem specification with respect to criteria such as freedom from deadlock and starvation. 
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sr 1 

Introduction and Background 

1.1 Goals of th« thesis 

This thesis is concerned with the problem of synchronizing accesses by concurrently 
executing processes on a shared data object. Overall the thesis has two major goals. One is 
to design a high-level language in which synchronization properties can be specified in a 
nonprocedural form. The other is to devise a method for translating such specifications 
into actual source fcrogttag*€Ode that implements the specified properties. 

The reliability of computer software has received a great deal of attention in recent 
years. The reasons are both economic and intellectual. Rapid advances in hardware 
technology have dramatically decreased the cost of hardware relative to software, as well as 
expanded the range of complex computer applications for which new software is required. 
As a result, the cost of producing and maintaining software has become more than ever a 
major concern. Since testing and debugging incorrect programs consume a large share of 
total software costs, methods for improving the reliability of software are increasingly 
important from an economic viewpoint. At the same time, the intellectual difficulty of 
producing high quality software has become more generally appreciated. The study of how 
to produce complex yet reliable software systems represents a fertile area for research. 



One productive approach in this area ha* £een the study of language support to 
enhance software reliability. The range of current, work, in the.area is quite broad, as 
illustrated by [LDRS77]. A particular aspect of this approach that has received wide 
attention has been the idea of abstract data types [LisKl l**»g«age support far-abstract 
data types gives programmers a facility for implementing data abstractions analogous to the 
capability provided by procedures for functional abstractions. Following a methodology 
using data abstractions has been found to be a significant aid in producing reliable 
software. 

A number of languages have been d eve l oped , and in ma*y que* implemented, that 
include mechanisms supporting the concept of abstract data types (e.g. [Lis77l [Sha77X 
[Ges77]). Because of a lack of facilities in these languages for creation of multiple 
concurrent processes and interprocess communication, their range of programs until recently 
has been restricted to single-process computations. However, it is obvious that many of the 
kinds of applications for which the reliability provided by data abstractions are needed, 
such as operating systems, require such multiprocessing capabilities. In introducing facilities 
for concurrency and interprocess communication into these languages, it is necessary to do 
so in a manner that maintains the philosophy and methodology that such languages 
support. 

This thesis explores a particular approach to a key problem in this area. The issue is 
the proper synchronization mechanism for a language that supports an abstract data type 
mechanism. Specifically, it is assumed that objects of abstract types in the language are 
shared among different processes and can be accessed concurrently. This means that some 
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sort of synchronization mechanism is required t» regulate these concurrent accesses. 
Synchronization may be required both to maintain the internal consistency of the objects 
and to implement higher-level scheduling decision*. 

The approach taken here involves specifying synchronization properties in a 
high-level nonprocedural language, and obtaining automatically an implementation for the 
specified property. Synchronizing concurrent accesses to data can be a complex, error-prone 
task. Since the reliability of programs that accmahared data depends upon the correctness 
of the synchronization, it is highly desirable that One synchronization itself be implemented 
as reliably as possible, if a specification language tan be developed that is powerful enough 
to express synchronization properties of interest, an* for which imptementatiom can b« 
synthesized automatically without too much effort, then it ca*bie incorporated into a source 
language that supports data abstractions. Programs in the source language can specify 
synchronization properties nonprocedural^ at a high level, and the compiler can produce 
the actual code using the synthesis algorithm. This would be a very attractive alternative to 
the range of synchronization mechanisms currently available, some of which are surveyed in 
the next section. 

1.2 Synchronization raeohanis»« 

Whenever concurrent processes share access to common resources, it is necessary that 
accesses by different processes be coordinated. The purpose of synchronization code, in the 
broadest sense, is to bring about this coordination. One kind of coordination involves 
limiting the combinations of simultaneous accesses allowed on a resource. That is, it is 
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sometimes necessary for certain accesses to exclude others from taking place at the same 
time. This may be because the resource can inherently support only a limited number of 
concurrent accesses. For instance, a physical device such as a card reader must be devoted 
to a single process at a time. Alternatively, the nature of the accesses may be such that 
certain kinds of accesses performed concurrently would lead to inconsistent results, such as 
the case of two simultaneous updates to a database. 

When certain accesses are prevented from occurring immediately, provision must be 
made for these deferred accesses eventually to ttke place. TWs is another aspect of 
coordination that must be handled by the synchronization code. Not only must a 
mechanism exist for deferring accesses. Decisions must be made as to when deferred 
accesses should occur, and these accesses must be activated in some way. 

In working on synchronization problems, it has been found that writing 
synchronization code is a conceptually difficult task, more difficult in general than writing 
sequential programs. This difficulty arises from the non-intuitive nature of many problems 
that arise in synchronization, and the combinatorial problem associated with different 
possible sets of concurrent accesses on a resource. Therefore, several generations of 
synchronization mechanisms have evolved, reacting to the Increasing complexity of 
concurrent programming applications, and to the resulting need for better, more 
well-structured synchronization mechanisms. 
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OriginaHy, concurrent processes communicated ^ttamigh common shared storage. 
Access to this common storage was usually conteoiledoby "tecfcs^V which were set prior to 
accesses and reset afterwards. Setting a tack was accomplished:; by means of an indivisible 
"test and set" instruction, usually implemented in hardware This mechanism was quite 
unstructured, and certainly did not provide great confidence in its reliabiUty. In addition* 
locking protocols involved ^usy waHing", so that a process prevented from performing an 
access because of an already set lock was forced to perform essentially useless computation 
while waiting for the lock to be reset. With the advent of multiprocess timesharing 
systems, this became unacceptable. 

An important step forward was the development of the sewajfeter^Jfiwchanism [Dij68], 
on which two operations are possible. Operation P accomplishes a "test and decrement" 
instruction, similar to setting a lock. However, the result of an un«ic«es»fuV "test" is te* block 
the given process and place it on a queue associated with the temaphore. This eliminates 
the need for busy waiting. Operation V increments the semaphore and dequeues a process 
from the- associated queue. With processes communicating via semaphores and using just 
these two operations, nearly all common synchronttation problems can be solved. In 
addition to solving the busy Waiting problem, semaphores, unlike locks, cart be required to 
be fair. This means that service is granted in such a way that a given process is not kept 
waiting indefinitely while an arbitrary number of other processes proceed. 
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A complete generation of akernativemechamsms then appeared, all of them in some 
way variations on the semaphore concept. The proposed alternatives were designed to 
improve somewhat on the power of the semaphore mechanism. A difficulty common to 
semaphores and these alternative mechanisins became apparent, however. They are at too 
low a level, comparable to goto statements in the area of control structures. While 

* 

sufficiently powerful to solve synchronization problems, they do not provide the 
programmer with enough structure to make these solutions easy to construct and reliable in 
operation. 

t 

Recent emphasis on "structured programming" [Dij72a] and language constructs 
suitable for producing reliable software has resulted in a new generation of synchronization 
mechanisms. Many of these new constructs attempt to internalize well-structured disciplines 
developed for the use of semaphore-style mechanisms, in much the same way that the while 
statement internalizes a structured style of writing loops originally developed using goto 
statements. Among the noteworthy mechanisms in this group are conditional critical regions 
[Bri72] and monitors [Hoa74], both of which embody the idea of accessing shared data only 
in indivisible segments of code. Both also seek to relate the scheduling mechanism for 
deferred accesses directly to properties of the shared data as another step toward better 
structure. More recent alternatives have attempted to improve further on these mechanisms. 
For example, serializes [Hew77] have drawn on experience with the use of monitors to 
build even more structure into the mechanism, and thereby correct certain perceived 
deficiencies in the monitor construct. 
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It is certainly easier to program solutions to non-trivial synchronization problems 
using these well-structured mechanisms than with semaphores or the like. However, 
synchronization remains an area of great complexity, and thus unreliability, in any large 
concurrent system such as an operating system or database management system. There is 
still a large conceptual gap between one's understanding of a synchronization problem and 
the code one must write to solve it. This has motivated recent work whose goal is to allow 
the expression of synchronization problems in a more natural form, and in some cases, to 
obtain automatically an implementation for the specified property. Some of this work, and 
its relationship with this thesis, is discussed in the next section. 

1.3 Specifications and synthesis 

Originally, synchronization problems were expressed simply in natural language. The 
informality of such descriptions was a contributing factor to the unreliability of the 
"solutions" proposed, as well as a source of controversy over just what a problem description 
"really" meant. After the widespread acceptance of semaphores, many problems were 
expressed via a representative program using semaphores. The circularity inherent in such 
a description is obvious, since the solutions to the synchronization problems also used code 
involving semaphores, and the distinction between "problem" and "solution" became 
negligible. More importantly, the expression of a synchronization problem at the level of 
actual code, while bridging the gap between specification and program, left the same gap 
between people's intuitive understanding and the specification. The "correctness" of 
specifications remained problematic. 
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A number of informal arguments about the correctness of «n algorithin or the 
meaning of a mechanism have relied on the notion of "state" to reason indirectly about the 
effect of synchronization code (eg, JHabT&l fll«$k {Dwi7$K Thi* approach vas used by 
Hoare in constructing formal p^oof rules for monitors in {Hoa74}. However, such an 
approach does not really formalize the meaning of synchronization code and 
synchronization problems themselves, but only m their relation to a program or system as a 
whole. Issues of modularity make it desirable to formally specify synchronization behavior 
in isolation from the procedures being synchronized.. 

Recent efforts to create structures through which to express synchronization problems 
include [Rob75], [Owi76] and [Cri76l [Gri76] contains in addition a System for synthesizing 
solutions from the specification language automatically. However, in all these cases what 
can be expressed is not a synchronization problem itself, but rather the abstract solution to 
the problem. This is an improvement over a "specification" in the form of a concrete 
program using semaphores, but it still does not allow the specification of a synchronization 
problem independent of its solution. In order to do so, it is necessary to have a 
nonprocedural language for describing synchronization behavior that is independent of 
notions of how to implement that behavior. 

Path expressions [Cam74] are a nonprocedural language for expressing 
synchronization problems. In addition, implementations can be derived directly from path 
expression specifications. Path expressions represent ,the. most nearly comparable work to 
this thesis, both in overall goals and in basic approach. A discussion and evaluation of 
path expressions will be deferred until the approach of the thesis has been fully presented. 
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A comparison of this approach with that of path expressions is presented in Section 8.4. 

[Gre75] introduces a theory and notation for describing system behavior, including 
synchronization behavior. This theory involves the notion of events, over which a time 
ordering relation is defined. The notation introduced in [Gre75] is very general, in keeping 
with the abstract level at which events are discussed. The specification language used in 
this thesis represents one approach toward refining and structuring that notation. 

1.4 Overview of the thesis 

The view of synchronization taken in this thesis is illustrated in Figure 1.1, which 
illustrates the sequence of events involved in accessing a synchronized shared resource. 
This view shares with a number of other recent approaches the importance of 
encapsulation. The unsynchronized resource to be shared and the synchronization 
mechanism for that resource are encapsulated into a single "synchronized resource" module. 
The details of the coordination between the two are hidden from the outside world, which 
can only access the resource through this higher-level module. 

The distinguishing features of the approach here concern the structure imposed on 
synchronized accesses of the resource. As indicated in the figure, every access involves a 
certain fixed sequence of events. The process wishing to make an access first communicates 
this desire to the synchronization mechanism, and this is denoted as the "request" for the 
access. When the synchronization mechanism permits the initiation of the access on the 
actual resource, the "enter" event occurs. The termination of the access is communicated to 
the synchronization mechanism in the "exit" event. 
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Figure 1.1. Accessing a synchronized resource 
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The specification language of this thesis is designed to describe properties concerning 
the time order of these abstract events. Chapter 2 presents this language, both its syntax 
and semantics, and includes a number of examples of its use. The synthesis of an 
implementation for the specified property is described in Chapters 3 through 5. Chapter 3 
describes the abstract solution specification structure, in which events are implemented by 
abstract notions called "gates". The algorithm for deriving an equivalent solution 
specification from a problem specification is presented in Chapter 4. Chapter 5 explains the 
implementation of a solution specification in actual code, where the abstract gates are 
replaced by procedures of a monitor. Several examples of complete synthesis for well-known 
synchronization problems are presented in Chapter 6. The detection of certain types of 
erroneous specifications, those that permit deadlock and starvation, is discussed in chapter 7. 
A summary and evaluation of the thesis is contained in Chapter 8. 
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Chapter 2 
The Problem Specification Language 

2.1 Introduction 

The focus of this chapter is on the language used for expressing synchronization 
constraints on accesses to an abstract data object. Before the language; itself can be 
presented, however, it is necessary to "set the scene" in terms of exactly what kind of data 
objects are being treated, what the nature of accesses to these objects js, and what kind of 
synchronization of these accesses is possible. These issues are discussed in the first two 
sections of this chapter. Then an overview of the language is presented, including some 
motivation. This overview should make it easier to understand the following two sections, 
which formally define the syntax and semantics of the language, respectively. The chapter 
concludes with some examples of using the language to express common synchronization 
problems. 

2.2 Data abstractions and synchronisation 

The data objects with which this thesis is concerned are of the sort that are handled 
in a language supporting the notion of abstract data types, such as CUJ([Lis77]) or 
Simula([Dah72]). A data object in one of these languages is strongly typed, which is to say 
that its data type is an integral part of the object, and represents a severe restriction on how 
the object can be used. In particular, there is associated with the abstract data type a set of 
basic procedures, or operations, An object of the type can only be accessed through these 
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operations, or through higher-level procedures that themselves make use of the operations. 
Furthermore, it is only these operations that are allowed to manipulate the lower-level 
representation of the abstract object. 

In general, an abstract object can be either mutable or immutable. An object is 
mutable if it has state, so that its behavior can change over time. Immutable objects do not 
have state, and once they are created they art fixed Tot all time. Thur they art not useful 
for communication between parallel processes, and consequently art not of great interest 
with regard to synchronization. The data objects treated throughout this thesis are 

* 

generally mutable. 

An operation of a data type whose objects are mutable can have the function of 
creating an object of the type with some (possibly parameterized) initial state, of accessing 
the object's state without modifying it, or of accessing and updating the state. Assignment 
of the object to a variable is not considered to be an operation on the object, but instead 
constitutes a (temporary) binding of the variable to the object See [Sch78] for a more 
detailed discussion of the semantics of a language such af CLU. 

Synchronization is considered here to impose a constraint on the otherwise 
unconstrained time Ordering of accesses to an individual data object. By this model, the 
ordering among accesses to different objects is completely unconstrained, except for the 
normal sequencing order within each individual process This means that if 
synchronization is required among accesses to several objects, then these objects must be 
collected together into a single composite object, with the synchronization applying to this 
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new higher-level object. It is important to keep in mind that it is the accesses on an object 
itself, not on any particular variable that happens to be bound to that object, that are of 
interest. Concurrent processes that share access to a data object presumably employ 
different variables for the purpose of referring to it, but it is over the total set of all these 
accesses that synchronization is required. 

This thesis will not be concerned at all with the exact mechanism by which there come 
to be concurrent processes, or with how such processes gain joint access to a shared data 
object. It is not important whether the processes represent concurrent users of a 
time-sharing system, or are created from one process by some sort of fork-join mechanism in 
the language. Nor does it matter if the shared object resides in some form of central library 
to which all processes have access, or if a reference to the object must be explicitly passed to 
each one. The issue of synchronizing accesses to an object by concurrent processes is 
independent of such concerns, and the work here applies regardless of how these issues are 
handled. The important point is that there are processes executing in parallel that 
concurrently access the shared object. Consequently constraints must be put on the time 
ordering of accesses to the data object, and this is the purpose of the synchronization. 

A basic assumption in the approach of the thesis is that the units upon which 
synchronization should be performed are the basic operations of the abstract data type. It is 
felt that the type's operations are the right level at which to impose synchronization 
constraints. Only these operations are allowed to access and manipulate the more concrete 
data representation of the abstract object, and so it is here that decisions by the implementer 
of the abstraction as to what pattern of accesses is necessary to maintain internal consistency 
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make sense. The centralization of these operations tea typfc module (such as a GLU 
cluster) permits a single expression of constraints to cover -all accesses of Ihe object. Since 
the language ensures that all accesses to the object are made through the basic type 
operations, the discipline required for synchronization can be enforced wilversally, which 
would not be true necessarily if higher-level procedures were chosen for synchronizing. On 
the other hand, to the user of an abstraction these operations are basic and the details of 
their implementation are unknown (and in fact can be changed without his/her knowledge). 
Synchronization constraints at any lower level, i.e. involving code internal to these 
operations, therefore would not be meaningful to the user. It is exactly at the level of the 
basic operations of a data abstraction that the two viewpoints of the imptementer and of the 
user can and should be resolved in a smooth interface. This is true for the synchronization 
component of the interface just as much as for the data component. 

A very strict division is assumed between the synchronization and data accessing 
functions involved in accessing a shared data object. This is based on the philosophy that 
the task of synchronization belongs in a separate language construct, whose sole function is 
synchronization. The operations of the abstract data type, on the other hand, should be 
completely unconcerned with this synchronization, and written assuming that 
synchronization exists that is sufficient to prevent any conflicts between concurrent 
operation activations. Synchronization is taken to be uniform across all objects of the same 
type, reflecting the belief that a type consists not only of data accessing operations but the 
synchronization on them as well. That is, all objects of a given type are synchronized in the 
same way. This means that the same (sequential) implementation of a data type and its 
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operations can be used with different synchronization constraints, perhaps embodying 
alternative scheduling policies or maintaining different levels of consistency, to create 
different data types. 

2.3 The guardian model of synchronization 

The model of synchronization that I use assumes there to be an abstract protection 
mechanism that conceptually surrounds each abstract data object on which accesses must be 
synchronized. (Recall the picture given in Figure 1.1.) This mechanism ensures that the 
encapsulated synchronization mechanism, which I call the guardian of the data abstraction, 
monitors all communication with the object, in a similar manner to the "secretary" concept 
proposed in [Dij72b]. Through this monitoring, the guardian is able to maintain the 
synchronization state of the resource, an abstract representation of the history of accesses to 
the object. (This is to be contrasted with the "data state" of the abstract object, which is the 
state explicitly manipulated by the operations accessing the object.) The guardian uses the 
synchronization state information to temporarily block any process attempting an access that 
the guardian deems to be unsafe given its current state. The blocked process is allowed to 
proceed when the synchronization state has changed in such a way that the access can safely 
occur. 

Accessing an abstract data object consists of invoking a procedure implementing one 
of the operations of the type to which the object belongs. A given procedure activation 
generates three distinct events that the guardian includes in the synchronization history of 
the abstract object. The first event occurs when the guardian first receives notice of the 
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invocation of the given procedure by the user process. i term this the request event for the 
.given procedure activation. A j-eqiiest event can be likened to the act of "taking a number" 
in a crowded bakery, and represents the very first externally visible occurrence associated 
with the particular procedure activation. 

The next event occurs when the process actually gains access to the object by 
beginning execution of the invoked procedure. I call this the enter event for the activation. 
It is this event that often must be delayed by the guardian until it can safely occur. Once it 
has occurred, the process may be assumed to be executing the body of the procedure. No 
assumptions can be made as to the relative execution speeds of different activations. 

When the process has completed execution of the procedure, it indicates this fact to the 
guardian and exits from the resource. This it the eaUt event* the last event involved in the 
activation. Frequently it is the exit event lor one activation that triggers a delayed enter 
event for some other activation. I 

This model of synchronization, of course, was not conceived in a vacuum. It is the 
result of a careful study of the kinds of synchronization properties that appear in the 
literature, which presumably reflect the nature of real-world concerns. Procedure entry and 
exit are natural concepts to use, since the basis of ninny synchronization problems is 
specifying which combinations of procedure activations can be allowed to execute 
concurrently. Clearly the solution of such problems require* that a record be kept of which 
procedure activation* are currently executing, that is to sfry, which activations have entered 
but not exited. Another large class of synchronizaiioniprc^erties. constituting what are 
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usually regarded as "scheduling" properties, involve decisions as to which of a collection of 
processes each waiting to execute some procedure is allowed to proceed first. In order to 
deal with such properties, it is important to keep track of what activations have been 
requested, hence the need for request events. My investigation of synchronization problems 
has failed to discover any other distinguished events associated with operation activations 
that are as fundamental as these three. Since this model appears adequate for capturing 
synchronization properties of interest, there seems to be no need for using a more 
complicated one. The examples at the end of this chapter, written in the problem 
specification language that is based on the guardian model, testify to its generality. 

The guardian model assumes that the set of aH events concerning a particular data 
object is totally ordered. That is to say, whfte fnanyp^oeedune activations can be executing 
concurrently, only one request, enter, or exit event associated With a given object can occur 
at a time. This total ordering property is comparable to the fact that the "arrival ordering" 
for any particular actor in [Hew73] is total, and relies ultimately on some sort of "arbiter" 
mechanism for each data object. 

2.4 Overview of the language 

The purpose of the problem specification is to express, in a clear and concise manner, 
an imposed constraint on the temporal order of accesses to abstract data objects of a 
particular type. To facilitate this goal, the language for expressing the specification has 
been designed to be as general as possible, subject to the requirement that it be compatible 
with the guardian synchronization model. That is, the guardian model paradigm of 
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request - enter - procedure body execution - exit forms j|he bawls of the language, but 
beyond this, the complete freedom of first-order predicate cafculos with equality and 
ordering among integers is available. Because of the power of predicate cakulus, any 
meaningful synchronization constraint that operates on Ae le»el of the time ordering of 
individual events can be expressed. 

This power, in fact, permits specifications to be written that must be judged erroneous. 
Such an invalid specification may, for instance, place a constraint on the circumstances 
under which a particular request event can occur, which would be incompatible with the 
guardian model. For certain kinds of erroneous specifications, the invalidity can be 
discovered in attempting to apply the synthesis algorithm presented in Chapter 4: The 
detection of other undesirable properties, namely deadlock: and starvation, can take place 
after the synthesis is performed, and this » the subject of Cbaptef 7< 

A specification is written for an abstract data type, and is intended to apply 
independently to every object of that type. The specification expresses a constraint on the 
ordering of accesses to the object, and represents the only such constraint. This means that 
any ordering of events that is consistent with the specification is valid, and in particular 
that procedure activations are allowed to execute in parallel unless constrained otherwise, by 
the specification. 
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The distinctive elements of the specification language concern events and their 
ordering in time. Time ordering between events is embodied in the "temporally precedes" 
relation, which is denoted by the infix symbol " ==» ", and which is adapted from [Gre75]. 
This relation is a strict partial order, transitive and anti-symmetric. The parallelism in a 
computation prevents the ordering from being total, but the set of events associated with 
accesses of a particular abstract data object is assumed to be totally ordered, as explained 
previously. 

Each activation of a basic operation on a given abstract data object is identified by 
the name of the procedure being called and the activation number. Procedure activations 
are numbered uniquely for each data object according to the (total) ordering of the request 
events associated with the activations. The convention used here is that activation numbers 
are written as subscripts to the procedure name. The sixth activation of procedure p (i.e. 
the activation associated with the sixth request for p) therefore is denoted "pg". 

A particular event associated with an access is denoted by adjoining to the procedure 
activation formula the event type (request, enter, or exit) as a superscript. For example, the 
exit event associated with procedure activation pg is denoted "pg" xlt ." Every event belongs 
to an event class, e.g. the p en,er event class consists of the events pj en,a, ( P2* n,er > etc - 

Activation numbers appearing in a specification can be any integer expressions, with 
important special cases being integer constants and variables. Constant activation numbers 
can be used to refer to a specific event of a particular class, such as the first one in a 
history. Variable activation numbers are more generally useful, though, since they allow 
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reference to a general member of an event class. In the absence of explicit quantification, 
activation number variables are assumed to be universally quantified. This Is a useful 
convention, permitting a specification that refers to even* pf*", for example, to represent a 
constraint on the enter event of any activation of procedure p. The use of expressions as 
activation numbers allows a specification to deal with related activations, such as pj and 

Pi*I 

It is possible, but not necessary, to include the arguments to procedure activations. If 
not included, they are assumed to be unimportant, and the specification applies to any 
activation of the particular procedure. Including the arguments to an activation can be 
useful for constraining these arguments in someday; and thereby limiting the applicability 
of the specification to those activations whose arguments meet the constraint. The identifier 
of the process malting the procedure activation cat* be used ai 6ne of the arguments of the 
procedure, so that if the identity of the particular process is important, it can be included in 
this way. 

The actual abstract data object on which the synchronization is being performed is not 
included as an explicit argument to any of the procedures operating on it. In this respect, 
this kind of specification resembles the "state machine" specifications used by Parnas for 
specifying the behavior of the operations of an abstract data type (see [Par72], e.g.). It can 
be assumed that operations are called by a mechanism such as the "dot" notation of Simula 
([Dah72]), by which operation p on abstract object x with arguments a and b is called via 
the statement "x.p(a.b)". A specification referring to operation p might list arguments a and 
b explicitly, but no reference would be made to object x. The specification would implicitly 
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apply independently to each object x of the given type. 

As an example of a specification expressed in this language, consider the following 
expression, which also appears as example 1 in Section 2.7: 

(p.«"«« =* q f<*«) z> ( Pi exit => qj en,,r ) 
This specification refers to two procedure activations, pj (the i-th activation of procedure p) 
and q: (the j-th activation of procedure q). Variables i and j appear free in the expression 
and therefore are universally quantified, and since no constraints are placed on the 
arguments to the procedure activations, the specification in fact applies to any activations of 
procedures p and q. The specification states that if the enter event for q: is preceded by the 
enter event for pj, then it is also preceded by the exit event for the same activation of p. 
That is, a currently executing activation of procedure p (on a given object) excludes a 
subsequent activation of procedure q (on the same object) until the activation of p is 
completed. Notice, though, that concurrent activations of p and q are allowed, as long as 
the activation of q begins (i.e. enters) first. 

2.5 Syntax of the language 

This section presents the syntactic rules for well-formed specifications. The notions 
identifier and arithmetic expression are assumed to be basic. An arithmetic expression is a 
series of one or more identifiers and/or integer constants separated by the usual arithmetic 
operations. The other notions are defined in terms of these two and each other. In each 

rule the concept being defined appears in italics: 

(1) A procedure name is an identifier. 

(2) A term is an arithmetic expression. 
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(3) An activation number is a term. 

(4) An activation name is a procedure name, subscripted with an activation 
number. *- 

(5) An activation expression is either an activation name, or an acjtfvatjpn name 
followed by a left parenthesis, followed by one or more terms separated by 
commas, followed by a right parenthesis. 

(6) An event type is one of the elem e n t s of the set {request t enter , exit J. 

(7) An event expression is an activation expression superscripted with, an event 
type. 

(8) An ordering clause is an event expression followed by the symbol =* 
followed by another event expression. 

(9) An arithmetic relation is one of the elements of the set 

Rel - {« , * .<,>.<. >} 

(10) Art argument constraint is a term followed by an arithmetic relation followed 
by another term. 

(11) A clause is either an ordering clause or an argument constraint. 

(12) A specification is defined by: 

(a) A clause is a specification. 

(b) If S is a specification, then (-• S) is a specification. 

(c) If S j and S2 are specifications and op is an element of the set 

Op Ha, v, 3,*}, 
then (Sj op S2) is a specification. 

(d) If S is a specification and i is an identifier, then V i (S) and 3 i (S) are 
specifications. 

The "argument constraints" defined in rule (10) may refer to the activation numbers 
and/or to the arguments to the activations (which are the "terms" in rule (5)). They may not 
refer to the actual abstract data object in question, however, since it does not appear as an 
explicit argument to any of the procedures. In fact, a general rule is that the arguments of 
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procedure activations to which predicates may refer are limited to immutable objects, such 
as integers. The interpretation of a relation on a mutable object would depend upon the 
point in time at which the relation is taken to apply, and might itself require 
synchronization on the given object. Rather than becoming involved in questions such as 
these, 1 choose to limit the predicates on activation arguments to immutable objects. This 
restriction does not appear to be severe. 

2.6 Semantics of the language 

The definition of the language whose syntax has been formally defined in the 
previous section can now be completed by means of a formal definition of its semantics. 
The purpose of the language is to express synchronization properties, that is, to constrain 
the order of accesses on an abstract data object. The semantics of the language therefore 
can be defined by specifying the collection of access histories that are valid with respect to 
any given specification in the language. This is accomplished by defining a predicate 
Valid(h, s), which decides for any history h and specification s whether h is a valid history 
with respect to the constraint expressed in s. First, however, it is necessary to define the 
concept of a history, and to restrict the concept to histories that are physically possible. 

The first step in this process is to define the notion of "event". An event is a 5-tuple 

<p, t, x, n, a>, such that: 

(1) p e P, the set of basic operations of all types. 

(2) t e ET, the set of event types, where ET ■ {request, enter, exit}. 

0-) x e Ob, the set of all data objects in the system, and p is a basic operation for 
the type of x. x is the data object on which the access is taking place. 
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<4) n € N\ the set of positive integers, n represents the activation number. 

(5) a is a vector laj, ... ■, a m ], where each element a| e Ob. a is the vector .-.erf' 

arguments to p. 

The types of the objects a|, ... , a m must match the types of the parameters to 

operation p. 

A partially ordered set of events forms a computation history, provided that the partial 
order fulfills the condition that each object history is totally ordered. An object history for 
data object z is a subset of a computation history, consisting of all events <p. t, x, n, a> in 
the computation history such that x - z. All events in an object history are on the same 
data object, so that the third component x of each event tuple can be eliminated, and each 
element of an object history is simply a 4-tuple <p, t, n, a>. Throughout the rest of this 
section, we will be concerned exclusively with object histories, though the simple term 
"history" will be used. 

Since the events in a history are totally ordered, the history may be considered to be a 
sequence of events. A sequence over a domain D can be defined as either the empty 
sequence [ ], or else the result of adding an element d € D to the end of a sequence s, which 
is given by the expression "add(s, d)". 

Not all histories are actually possible. In order to define what class of histories are 
possible, some further definitions are required. An event class for a data type dt is a pair 
<p. t>, where p e P and t € ET, and p is a basic operation of data type dt. The set of 
occurrences of an event class <p, t> in a history h is a set of pairs of the form <n, a>, where 
n is an activation number and a is a vector of arguments, such that an event of the form 
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<p, t, n, a> occurs in history h. Formally, this is given by Occurrences(h, <p, t>), where: 

Occurrences([ \ <p, t>) = { } 
Occurrences(add(h, <pj r tj, n, a>), <p, t>) = 

if (p - pj a t - tj) then Occurrences(h, <p, t>) U {<n, a>} 
else Occurrences(h, <p, t>) 

With the aid of these definitions, we can now define when an history is possible. The 

predicate Possible requires a request event to precede the corresponding enter event, which 

in turn must precede the corresponding exit event. Also the ordering of request events for 

a given procedure must determine the numbering of invocations. 

PossibleO = TRUE 
Possible(add(h, <p, t, n, a>)) = 

Possible(h) a 

((t = request a Occurrences(h, <p, request>) - {<i, a 4 > 1 1 < i < n}> v 

(t = enter a <n, a> e Occurrences(h, <p, request>)) v 

(t = exit A <n, a> e Occurrences(h, <p, enter>))) 

A few more definitions are required before the validity of a possible history with 
respect to a specification s can be defined. An event expression is a 4-tuple <p, t, exp, v>, 
where p e P, t e ET, exp is an arithmetic expression, and v is a vector of arithmetic 
expressions, possibly empty. (The concept of arithmetic expression can be defined formally 
in the obvious manner.) Let the set of arithmetic relations Rel » {=, *, <, >, <, >} and the set 
of logical binary operators Op •= {a, v, 3, **}. Then the set of event expressions in a 
specification s is given by Evexp(s), which is defined in the obvious manner: 
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EvexpW, =*B 2 > - { ej ,e 2 J 

Evexp(exp| rel exp 2 ) - { }, for rel e Rel 

Evexp(-« s) » Evexp(s) 

Evexp(sj op $2> - Evexpty) U Evexp^), for op € Op 

Evexp<3 x (s)) - Evexp(s) 

Evexp(V x (s» - Evexp(s) 

An interpretation is a mapping f from expressions to data objects that preserves the 
meaning of all constants and operations. That is: 

(1) f maps every constant expression to the corresponding constant object, 

e.g. f(l) - 1 

(2) f is consistent with every operation, 

eg. f(exp, ♦ exp 2 ) - f(exp,) ♦ flexpg). 

(3) f maps a vector of expressions into the corresponding vector of objects, 

e g. f(<exp,, . .. , exp m >) - <f(exp 1 >, „\ f(exp m >>. 

An event e and an event expression ee matcA under an interpretation f if e and ee are 

of the same event class, and f maps the activation number expression and parameter vector 

expression (unless the latter is empty) of ee to the corresponding components of e. Formally, 

Match(e, ee, f) is defined as: 

Match(<pj, t|, n, a>, <p 2 , t 2 , exp, v>, f) - 

<Pl " P2^ A fy " l 2* A W**p) " ") A tv - t ] v f(v) » a). 

The validity of a history with respect to a specification s can now be defined by a 
predicate Valid. The definition of Valid recursively determines when a history is valid 
with respect to a specification. For a history to be valid, the previous history consisting of 
all but the last event must first be valid. Furthermore the last event in the history must 
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satisfy the specification for all interpretations under which the event matches some event 
expression in the specification. 

' Whether or not an event added onto a valid history satisfies a specification under an 
interpretation is defined by another predicate Sat. The definition of Sat for a complicated 
specification is basically just a matter of breaking down the structure of the specification, by 
removing each logical operator and applying it to the recursive applications of the 
definition, until one reaches the level of a simple clause. Satisfaction of an argument 
constraint is determined solely by how the components of the clause are embodied by the 
given interpretation, not by the event in question. Whether an event satisfies an ordering 
clause depends upon whether the event matches one of the event expressions in the clause 
under the interpretation. If the event matches the first event expression under the given 
interpretation, then it is necessary that no event matching the second event expression 
occurs in the previous history. If the event matches the second event expression, though, 

then some event matching the first event expression must occur in the history. 

# 

Formally, if h is a possible history and s is a specification, then h is valid with respect 

to s if and only if Valid(h, s), where: 

ValidU 3. s) = TRUE 
Valid(add(h, e), s) = Valid(h, s) a 

V (ee, f) (ee e Evexp(s) A f is an interpretation 

a Match(e, ee, f) => Sat(h, e, s, f)) 

The predicate Sat(h, e, s, f) determines whether event e added to history h satisfies 

specification s under interpretation f. It is defined by the following equations, giving all 

possible cases for specification s: 
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Satfli,*; (<pj, t,, e*pj, v,> s*> <p2,t2, exp£, v^>), f) - 
(Match(c, <pj, tj, expj, vj>, 3 

((v 2 * [ ) a <f(exp2), f(v2>> * Occurrences(h, <p 2 . t2>» v 
(v 2 - [ ] a V a (<K<xp2). «> #0ca*rre«ces<h, <p2» *£>)»)) 
a (Match(e, <p2> t2> exp«, V2>, 3 

((vj * [ ] a <f(expj), f(vj)> € Occurrences(h, <p 2 , t 2 >» v 
(vj-[3 a 3 a (<f(exp!), a> e Occurrences{h, <p,, tj>))))) 
Sat(h, e, exp, rel expg, f) - (f(cxp|) rel jgtexpg)), for rel fcRel 
Sat(h, e, -• s, f) - -• Sat(h, e, $|. 

Sat(h, e, sj op $2, - Sat(h, e, Sj, f) op Sat(h, C$2.0. for op e Op 
Sat(h, e, 3 i (s), f) -3m Sat(h, e, dm/H r) 
Sat(h, e, V i (si f) * V m Sat(h. «* suWil. 8 
The notation s[m/i] in the last two equations represents the expression resulting from 

substituting m for all free occurrences of i in s. 

2.7 Examples 

This section presents a series of examples of the use of the problem specification 
language. These examples have been chosen with two criteria in mind. First, together they 
illustrate the range of features that the language offers. Second/they specify realistic and 
representative properties, covering a significant portion of the classic synchronization 
problems that appear in the literature. 

Example 1: Exclusion 

(p ..nt.r _^ «H,rj ■> (p «H ^ q wtor) 

This specification has been discussed previously in Section 2.4. It states that an activation 
of procedure p excludes a subsequent activation of procedure q until the activation of p is 
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completed. 

Example 2: Mutual exclusion 

(p. •** =>.q •"«•') v (q •"«=* p. •"*•') 

This specification is similar to example 1, except that it is symmetric between procedures p 
and q. That is, an activation of either p or q excludes any eoikurrent activation of the 
other. 

Example 3: Readers-writers property 

((write^"'" => write: ,n,,r ) 3 (write^** => writej' nUr » a 
((write^"" =» read k ,n,,r ) v (read k ,Ki ' =* write^"'"')) 
The so-called readers-writers property concerns two operations, -"jfcad" and "write". Ft states 
that activations of "read" exclude those of "write*,* and that an activation of "write" excludes 
all other activations of either operation. This has been re-shaped into an instance of 
example 1 (an activation of "write" excludes all other activations of "write"), and an instance 
of example 2 {activations of "read" and "write" mutually exclude one another). By 
combining this specification with an instance of example 4, giving one of the operations 
priority over the other, or of example 5, requiring an equal-priority first-come-first-served 
discipline, one can obtain any of the classic versions of the readers-writers problem (as 
found, for example, in [Gre75]). 

Example 4: Priority 

( Pi "*™« =* qj """) z> ( Pi ' n,w ■* qj M ** r ) 
This specification gives priority to activations of procedure p over tttose of procedure q. It 



-30- 

does this by requiring that so long as the activation of q has not yet entered, then any 
activation of p that has been requested must enter first, regardless of whether the request 
event for p came after the request event for the activation of q. This is an example of a 
scheduling property making use of a request event. 

Example 5; FCES scheduling -~ 

(p.request ^ q *«i«t) „ ( p .»rtw _> q TOtef) 

J J 

This specification represents an alternative to giving either of a pair of operations priority 
over the other. Instead it requires a strict first-come<first-served discipline between them, by 
stating that whichever activation is requested first is the one to enter first 

Example & LCFS scheduling 

(p . request ^ p^Wt) A (pf"*** f-» pf**) 3 (pf"*" ** p^'") 

Here another alternative scheduling policy, though probably a less likely one, is specified. 
This "last-come-first-served" property requires that of all the requested and pending 
activations of a given operation p, the one most recently requested ts allowed to enter. 

Example 7: Operation pairing 

(».•»*•' =» *,«*•<) ♦• (cf*" => d j r ,tor ) 

This specification requires that whichever order occurs between the entry of an activation of 
"a" and one of "b", the same order must hold for the corresponding activations of "c" and 
"d", respectively. Illustrated is the use of the same activation number for activations of 
different procedures, i for procedures "a" and V, and J for procedures "b" and "d". The 
specification could be used for a data type m which operations * and b conflict, in the sense 
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of updating the same part of the object's state, as do operations c and d. If operations a 
and c. taken as a pair, update the, state consistently, and operations b and d do likewise, 
then the constraint specified here might be necessary to prevent an inconsistent update. 

For example, in [Esw76], an example is given for which, th« operations have the 
following meanings: 

a: X :- X+10, 

b: x :■ x*2; 

C: y := y+IO; 

d: y :- y*2; 
If the predicate (x - y) is the criterion for consistency of the data object, then this would be 
part of the specification required. (Other constraints also w;ould be necessary.) 

Example 8: Producer-consumer (single buffer) 

(depj** 1 =*rem i ,n, n A (rem i wrt =* dep i+ , ,rtw ) 
The "producer-consumer" problem is that producers and ^consumers, must alternate in 
depositing and removing messages, respectively, in a shared buffer. This means that each 
deposit, represented here by an activation of procedure ."dqj", must precede the 
corresponding removal, or activation of procedure "rem". On the other hand, the removal 
must take place before the next deposit can occur. This specification again illustrates the 
use of -the same activation number for activations of two different procedures, as well as the 
use of an expression ("i+1") as an activation number. Notice that this specification could be 
rewritten so as to make the relationships between activation numbers more explicit by 
means of predicates on the activation numbers: 
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<i - j) D (dep^* =*remj" tt TA ittitif* =* depj + f" ,w ) 
This specification is exactff equivalent to the original; it rrtakeS no difference whether such 
relationships are represented expncitty or implicitly - *r c -.<■*>.. 

Example 9: Bounded buffer *^ 

(de Pi mxA =* rem^) A (rem i MH => dep^""^ a 

(depj"" => dep i4l w,tar ) a (remj'"* -* rem^,*"**') 

This example is a generalization of the previous one, in that the activation number of the 

de p«m.r event haj |jeen cnanggj f rom i+ j to ^ t f or g^^ integer N. The specification is 

for the same problem, except that the size of the buffer is now N. This means that up to N 
messages can be deposited in the buffer benWfHWroj if. So that up to H successive "dep" 
operations can be a I towed before one has to Wait for a # rern" operation. The last two 
clauses state that the individual "dep" activations must be mutually exclusive and execute in 
first-come-first-served order, as must the individual "rem" activations. 

Example Id: Intervening activation 

(p«a => Pj «**) o (3 k ( Pi M * => -<tf*" A q^M-^p^)) 
This specification represents a weaker property that is implied by the producer-consumer 
constraint of example 8. It requires that between any two activations of procedure "p" there 
must be an activation of procedure "q". This shows the use of an existential quantifier in a 
specification to require a particular kind of event to occur at a given point in the history. 

Example 11: Threshold of requests 

V i «k < i) A (i < k*N) D (pf*** => p k w,taf )) 
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This specification places a threshold of N request events for activations of procedure "p" 
before the first one can execute. Since this applies to any value of k, the result is that 
whenever an activation of procedure "p" is currently executing, there must be at least N 
processes that are waiting on requests to execute "p". 

Example 12: Exclusion on a restricted class of accesses 

(p . (a) .n«.r ^ q . (a) .«1.r) -> (p . (a) .x.t ^ q . (a )">t.r) 

This specification is identical to example 1, except that a parameter has been given to each 
of the two procedure activations. By providing the same identifier as the argument to both 
activations, this specification conveys the information that the arguments to the two 
procedure activations are equal. Therefore the exclusion constraint expressed by this 
specification is restricted to activations with equal parameters. 

Example 13: Predicate locks 

c( a ,b) a ( Pi (ar'" =» q^br 1 -') o (p^r* => qj (br ,,r ) 

This specification again represents a restriction of the exclusion constraint of example 1. 
Here, though, the restriction is represented by a general predicates C on the parameters to 
activations pj and q;. This suggests how a simple version of the concept of "predicate locks" 
might be specified. A specification of this form can be used to state the synchronization 
constraint, as long as the predicate C for which exclusion is required is known ahead of 
time. 
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For exa mple, suppose^ thaj the abstract data object on - which procedures "|>"-; and "q" 
operate is a tywarchicalb/organiMd database The daubaifrcoBsists of a collection of files, 
each of which in turn consists of a «>ll«c*icfl of record*.? Thepredicate C might express the 
relation that records a and b are element* of the same file Therefore, procedure "p" would 
exclude procedure "q" only when they were operating on records in the same file. 

The general notion of "predicate; locks" ■•'we* irtfrodyced in tEsw76l The more 
complicated versions of the concept discussed there would require more complex 
specifications. ; ■■ -.'.-■ 

Example 14: Disk head scheduling 

«a ? ,nUr =* a y ,ntar ) 3 (if* =» a ¥ w,tor )) a 

((a i (x2) rw ^ Ht => a^xir" -» ifaSir*) a 

(aj(x3) r • , ^• , *► a k (xir H => a^r^A 

(a tn (x0r a '^* k <xl^)) a 

- 3(n) ((^(xor 1 * *» afl"" 1 => a^xir*)) A 

((x0 < xl < x2 A <x2 < x3 v x3* x|)) v 

(xO > xl > x2 a (x2 > x3 v x%> xl)» 

D (a^r 1 " *^aj<x3r^) 

The final example is the "disk head scheduler" problem, which appears in {Hoa74i among 

other places. The problem is to schedule disk accesses so as to minimize average waiting 

time. The way this is done is to have the disk head sweep in one direction, accessing each 

track it encounters for which an access has been requested, until no more requested tracks 

remain in the direction in which it is sweeping. The head then reverses direction and 
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sweeps back, again accessing requested tracks as it encounters them. The essential idea is 
that at any given point, the next track to be accessed is the one closest to the currently 
accessed track in the direction currently being swept. 

The specification for this problem concerns four activations of an access procedure "a" 
on a disk, with the parameter (xO, xl, x2, or x3) representing the number of the track being 
accessed. The constraint expressed is that of the two activations (aj and a:) requested 
during the time that another activation (a^) is executing, the activation allowed to execute 
first is the one accessing the track nearest to the track currently being accessed (track xl) in 
the direction currently being swept. The direction is indicated by the inequality between xO, 
the track that most recently accessed, and xl. Track x2 is accessed before track x3 either 
because it is closer to track xl (either xl < x2 < x3 or xl > x2 > x3), or else because it is in the 
right direction and x3 is not (x3 < xl < x2 or x3 > xl > x2). 
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Chapter 3 
The Solution. Specification 

3.1 Introduction 

There is a vast conceptual distance separating, on the one hand, a problem 
specification written in the language described W Chapter 2, and on the other, the 
synchronization code that implements the specification. This is because the specification is 
a non-procedural, requirements-oriented expression of wAar should happen with no 
indication of the means by which this behavior should be realized Determination of the 
procedural mechanism, that is how to accomplish the desired constraint on the time order of 
accesses, requires a fundamental transformation in concepts. Once this determination has 
been made, there are still a number of details that need to be worked out, but the remaining 
work is basically that of the back end of a compiler, translating from an intermediate 
language into actual code (though the target code in this case is still in a high-level 
language, not machine language). 

I have chosen to split the derivation process into two stages. The first stage is the 
transformation from procedural to nonprocedural form. It can be described without 
reference to the exact details of particular source language constructs. The second stage 
constructs an actual implementation. The intermediate form into which the problem 
specification is transformed by the first stage is called the solution specification. This 
chapter presents an informal description of solution specifications, followed by a formal 
definition of their semantics. The method for transforming a problem specification into an 
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equivalent solution specification is the subject of.^iyfpter 4. The translation of the solution 
specification into synchronization code is treated in Chapter 5. 

Section 3.2 presents the "basic" structure of the solution specification, which is only a 
first approximation to the actual structure. The basic structure described is quite simple 
and elegant, and in fact the solutions *o=wny »^broru*at*on problems can be expressed 
within it. Unfortunately, this simple structure lacks sufficient expressive power for certain 
important classes of problems. For this reason* it irneeessarf to augment the basic structure 
with additional features whKh are dewioed m Se^toft 33. The formal semantic definition 
of the solution specification appears in Section 3.4. ^_ 

3.2 The basic solution specification structure 

The structure of the solution specification, a* of tht problem specification, u dictated 
to some extent by the guardian synchronization model. That is, the solution specification 
must contain features corresponding to Ihose event* associated with procedure activations 
that the guardian model distinguishes. Beyond this, there is aome choice as to bow rigid a 
structure to impose on the solution specification. Since the solution specification is an 
intermediate form between the problem specification and the generated code, the degree of 
flexibility represents to some extent where it lies on the spectrum between these two 
structures. A very general solution specification structure, corresponding to the generality of 
the problem specification language, would represent a decision that the solution specification 
be relatively close to the problem specification. The price paid for this generality would lie 
in the difficulty of translating such a solution specification into target code. 
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The alternative choice made here is for the solution specification to have a rather 
rigid structure. This means that, as indicated in the introduction to this chapter, the 
fundamental transformation takes place in deriving the solution specification from the 
problem specification. 

The basic structure of the solution specification is for each guardian to consist of a 
collection of gates through which processes accessing the abstract data object must pass. 
The use of the term "gate" is taken from [Rob753, though the concept as used in this thesis 
differs somewhat from the one introduced there. Specifically, the guardian for an object of 
abstract data type t contains a gate for each event class of t. This means that for each 
operation p of the abstraction, there are gates p r,< ' u,s, F p en,,, I and p" xl1 . Each event 
associated with an object corresponds to the passage through a gate in its guardian. For a 
process to access the data object by activating procedure p, the process first must pass 
through the p 1,6 ^ 68 ' gate, then through the p en, ' r gate. At this point it executes the body of 
procedure p, after which it must pass through the p™" 1 gate. 

Each passage through a gate by a process produces a (conceptually instantaneous) 
change in the state of the guardian. Because of thetotal ordering on the events associated 
with an object, the gate passages for a particular guardian are totally ordered. The 
ordering of processes passing through any single gate is first-come-first-served. This means 
that unless a specification explicitly requires a particular scheduling policy for activations of 
a given operation, the default policy assumed is first-come-first-served. The order of service 
among different gates of a guardian is assumed to be fair, in the sense that processes at 
different gates have equal chances of being chosen for service. That is, a requirement in 
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the implementation is that a process cannot starve because of tack of attention from the 
scheduling mechanism. 

Gates for request and exit event classes are unconditional, so that processes cannot be 
blocked in passing through these gates. A gate for an enter event class is conditional, 
however. Associated with each entet fate there is some condition on the guardian state. 
This condition must be satisfied in order for the process making the activation to pass 
through the gate. If a process attempts td pass through an enter gate whose condition is 
not satisfied, then the process is blocked, and must wait until the condition becomes trtw 
before proceeding through the gate. 

Schematically, then, an activation of operation' p on a data object is implemented by 

the abstract program below. Since gate passages represent events, which are totally ordered, 

the abstract code representing each gate can be considered an indivisible operation. 
pr*quesf. update g Uarc |i an j^g 
p enUr : wait until entry condition is satisfied, 

then update guardian state 
execute body of operation p 
p <,xrt : update guardian state 

It would appear that to represent a given solution specification, it would be necessary to 
specify for each operation p the specific entry condition on gate p™**', and the particular 
updates to the guardian state accomplished in each of the three gates. In fact, the form 
chosen for the synchronization state of a data object defines a priori the nature of the 
updates within all gates. 
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The history of a data object, and of the guardian for the object, consists of the totally 
ordered sequence of events associated with all accesses of the object in the entire 
computation. The state of the object represents some abstraction from the history that is 
sufficient for predicting its future behavior. An alternative way of saying this is the 
definition in [Gre75] that a state is an abbreviation for a class of histories. The 
synchronization state of the object is the synchronization component of the state, which is 
sufficient for the prediction of its future synchronization behavior. 

The decision made here is to express the synchronization state of an object as the 
number of events that have occurred at each gate of its guardian. The notation used is 
that count(g) denotes the number of events at gate g. So coullt(p'' equ " 8, ) is the number of 
activations of procedure p that have been requested, whether or not those requests have 
been granted; count(p en,er ) is the number of activations of p that have entered, whether or 
not they have exited; and count(p ex,t ) is the number that have exited. 

This decision has a number of ramifications. The implications for the expressive 
power of the solution specification are discussed in the next section. The decision to use 
counts forms the basis for the method of deriving a solution specification from a problem 
specification, as will be apparent in the description of the derivation algorithm in Chapter 
4. With respect to the basic structure of the solution specification, it means that in the 
schematic abstract program representing an activation of operation p, each update to the 
guardian state now can be defined to be simply incrementing the proper count. The 
abstract program therefore becomes: 
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p r«»urtt : mcrelwcm coutit(p r ^ u ^') by I 



then increment counttp" 1 ^) by I 
execute body of operation p 
p M *S increment couwKp'^by I 

That is, the update to the synchronization state within each gate consists simply of 
incrementing the count of events at that gate by I. (The quantity count(g) is similar to, and 
in fact can be implemented by, the "eventcount" notion introduced in [Ree77]). 

This means that the representation of a particular solution specification can consist 
simply of the entry condition on gate p* Bl * r , for each operation p of the abstract type. Each 
entry condition on the synchronization state must take the form of a predicate on the counts 
of gates. The other (non-enter) gates in the solution specification are indicated implicitly by 
the appearance of quantities of the form count(g) within the entry conditions. 

For example, consider an abstraction with one operation "op". Suppose that the 
synchronization constraint for this abstraction requires activations of op to be mutually 
exclusive, that is, at most one activation is allowed to be executing at a time. Then the 
solution specification for the abstraction can be expressed by stating the condition for gate 
op ,nt-r tobe 

coun^op"^ - couBt(op" H ). 
This is a shorthand way of saying that the abstract program for accessing an abstract data 
object via operation op is: 
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op r • < ' • s, : increment coullt(op r • , ' urt, ) by I 

then increment count(op*$ w ) by i 
execute body of operation dp 
op"'': increment coullt(op• )< ' , ) by 1 

As a second example, consider an abstraaion with two operations f and g. Assume 
that an activation of operation f is allowed to begin execution only if no activations of g 
have been requested and are waiting. Also, let an activation of g be able to enter only if 
exactly one activation of f is actively being executed^ Then the solution specification for 
this abstraction consists of the two entry conditions: 

For gate f ,ntor : couiit<g r *^^ - couht(g**^) 

For gate g'"'*: count(f* ntor ) - coun^f*** 1 ) - V 

In other words, the following are the abstract programs for activations of f and g: 

Abstract program for f: 

r"" 0-8 ': increment counKr"^ 8 ') by 1 

f*""': wait until couhUg riq ^ - count(g**^), 

then increment <M«nt(f^f^ by I 
execute body of operation f 
f* M : increment count(f™"') by 1 
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Abstract program for g: 

gr.qu.st. i ncr ement count(g r ^»» , KI)yl 

g" n,er : wait until count(r" u, >-COWH^)-l, 

then increment count(g*" tar ) by t 
execute body of operation g 
g"""': increment count(g• , " , ) by 1 

3.3 Additional features of the solution specification 

As indicated in the introduction to this chapter, the basic structure presented thus far 
for the solution specification lacks sufficient power for expressing solutions to, a wide class of 
synchronization problems. Two new features must be added to this basic structure in order 
to achieve the required expressive power. These additional features^ which are the subject 
of this section, provide the ability to save and use previous state information, and the 
ability to use properties of parameters to operation activations. The first to be discussed is 
the use of previous state information. 

In the previous section, the synchronization state was defined as some abstraction from 
the history of a data object containing sufficient information for the prediction of the future 
synchronization behavior of the object. Unfortunately, the counts of all event classes do not 
provide sufficient information. Sometimes it is necessary to know not only how many events 
of each class have taken place previously, but in what ordtr certain of these events occurred. 
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There are a number of advantages to using integer-valued counts to represent the 
synchronization state. As illustrated in the previous section, it makes the abstract state 
update within each gate of the guardian particularly simple. As a result, the actual 
implementation of a solution specification in terms of a source language synchronization 
mechanism, which is the subject of Chapter 5, can be both simple and efficient. This 
efficiency is important in ensuring that the synchronization code itself does not significantly 
affect the concurrency of the computation. The use of counts is also important in terms of 
the algorithm presented in Chapter 4 for deriving a solution specification from a problem 
specification. For these reasons, it is desirable to remedy the lack of expressive power in a 
way that does not sacrifice the advantages of using counts of events as the basic form of the 
synchronization state. 

The way to accomplish this is to add to the basic solution specification structure the 
ability to save the synchronization state at the time of an event. The state of the guardian 
then includes not only the current synchronization state, but also each previous state that 
has been saved. Conditions on enter gates can be expressed in terms of both the current 
synchronization state and any information saved from previous states. All the information 
that is lost by abstracting from the complete sequence of events within the history to the 
counts of event classes can be regained by using the state at the time of prior events as well 
as the current state. Basically the reason for this is that when it is necessary to know 
whether some particular event ej has preceded some other event e 2 in the preceding 
sub-history, this information can be obtained by comparing information in the states when 
ej and e 2 occurred with the current state and/or each other. In Chapter 4 it is explained 
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how previous state information is derived to express properties for which the current state 
is insufficient. 

A notationat extension is needed to represent previous state information. Unless 
indicated otherwise, quantities appearing in a condition represent current state values. 
When a quantity is meant to represent a value in the state at some previous event, the 
notation M e g" appended to the quantity is employed, where g is the name of some gate. 
This means that the quantity refers to the state saved just prior to the most recent event 
occurring at gate g. For example, the number of activations of p that had been requested at 
the point at which the most recent exit event for procedure q has occurred is denoted 
[co^Int(p r • < « u • 8, ) a q MH l Notice that since the state is saved just before the indicated event, a 
quantity such as tcount(q Mit ) e <f**] does not include the q - * 1 * event actually occurring at the 
point at which the state is saved. 

As an example of a solution specification that uses previous state information, consider 
an abstraction with two operations u and v. Suppose that it is desired not only that 
activations of operation u be mutually exclusive, but that between any two successive 
activations of u, an enter event for operation v must occur. This can be expressed by the 
condition 

count(u ,n,,r ) - count(u OTrt ) a tcount(v wrt,f ) • u ,xH ] < count(v OT,#f ) 
for gate u #n,,r . The second conjunct of the condition says that count(v #nUf ) must increase 
between the exit event for the most recent activation of u and the time the next activation 
of u is allowed fo enter. The corresponding abstract program for an activation of u is: 



-52- 
u requcst. increm ent count(u r " qurt ') by 1 

u en»er. wajt unU| C0Ullt ( u en»") = cOUIlt(u e,ti, ) A 

[count(v en,er ) s u Mil ] < coul1t(v• n, • , ), 

then increment count(u en, * r ) by 1 
execute body of operation u 
u' Krt : save the guardian state, in particular the quantity count(v ,nUr ), 

and increment count(u ex,t ) by 1 

Each event at gate u en,,r uses the value of count(v en,,r ) saved at the most recent u" rt event 
in its entry condition. 

As before, a solution specification is represented simply by the entry conditions that 
apply to all enter gates in the guardian. The state information that must be saved is not 
listed explicitly. Instead it is indicated implicitly by the appearance of quantities of the form 
[count(ec) @ g], where ec is an event class and g is a gate, within entry conditions. 

There is another aspect of information that is lost by abstracting from the history of 
an object to simply the count of events in each event class. The history is a sequence of 
events, each of which is described not only by its event class, which is to say the operation 
name and event type, but also by the vector of parameters passed to the operation. AH 
information concerning the values of these parameters is lost when considering only the 
counts of event classes. For instance, it may be necessary for activations of an operation to 
be mutually exclusive only if an integer parameter of each activation is non-negative. Such 
a property can be expressed in the problem specification language of Chapter 2, but not in 
a solution specification with the structure presented thus far. 



The solution is to "qualify" gates in the solwton specification. A, gafte to qualified by 
the attachment of some predicate on the parameters of the associated procedure activation. 
Only if the parameters of an activation satisfy the predicate does the process making the 
activation pass through that gate. An unqualified ga|e, which applies to a# activations of 
the given procedure, may be considered to be simply 1 a special case of a qualified gate, with 
a qualifying predicate that is identically TRUE for all parameter values. 

Some new notation is needed in order to refer to gates. An unqualified gate, as before, 
is indicated simply by the event class it is in, such as the p wrt#f gate. A qualified gate is 
denoted by appending the qualifying predicate to the procedure actuation expression. The 
notation used is similar to that employed in set theory, with a vertical bar used to separate 
the predicate from the activation expression. Therefore, 1|Kvy | dfv>3* nli * denotes a gate in 
the p" n1 * r event class that is qualified by the* predicate C oh the "vector of paiarrteteirs ; r to 
procedure p. 

As an example, consider the following situation. Let an abstraction have one 
operation h, taking a single integer parameter x. Let ill activations of h with non-negative 
parameter values be mutually exclusive. Then the solution specification contains the 
condition 

count([h(x) | (x > Or 1 *) - eottiit<[h(x) | (X > OW*) 
for gate [h<x) I (x > 0)] w, * r . This means that thr gate! fbr both the h*"** and h™* event 
classes are qualified with the predicate (x 2: 0), and that any activation of h whose 
parameter does not satisfy this predicate need not pass through these gates. That is, the 
abstract program for an activation of h with parameter x is: 
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Request. i ncremen tcount<h requ " M ) by 1 
h" nUr : if x > then 

wait until cou»t([h(x) | (x > 0)1"*-) - count(th(x) | (x > 0)]" rt ). 

and then increment cduht([h(x J 1 (x i (J)]*"**) by 1 
execute body of operation h with parameter x 
h exrt : if x >0then 

increment pount([h(x) | (x > 0)7**) by 1 

Since gate h r " qu,9t is not qualified, all activations must pass through it, regardless of their 
parameters. 

Allowing only one qualifying predicate for an event class would be overly restrictive. 
It may be necessary to maintain counts of several different subsets of events in an event 
class, where each subset is distinguished by a different predicate on the operation 
parameters. These subsets may either be disjoint or overlap. Also, different entry 
conditions may be required for different subsets of the total set of activations of an 
operation, and again these subsets may be disjoint or overlap* It i& therefore necessary to 
generalize the above structure by allowing more than o©e .gate for each event class. Each 
gate in an event class is distinguished by a different qualifying .predicate, and each gate of 
an enter class may have a different entry condition as *»M. When there is more than one 
gate for an event class, a process passes through exactly that set of gates whose qualifying 
predicates are satisfied by the parameters of the activation, jt is making. These gate 
passages are assumed to all occur in parallel. It is this simultaneous passage through a 
subset of the gates in an event class that implements the abstract notion of an event. 
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The implementation of each event class fry a whole set of gates is a fundamental 
change in the structure of the solution specification. It is perhaps best understood by 
looking at the new abstract* program for an activation of operation p with parameter vector 



pr«qoest. in p^iki f or a |j g ates g m cve nt class p r 
if v satisfies the qualifying predicate of g, 
then increment count(g) by J 
p ,nUr : in parallel for all gates g in event class p*" tor , 
if v satisfies the qualifying predicate of g, 

then wait until the entry condition of g is satisfied, 
and then increment coaWKgiiifl 
execute body of operation p 
p" cit : in parallel for all gates g in event class p n *, 
if v satisfies the qualifying predicate of g, 
then increment countfp* 1 ") by I 

Since the events in an object history are totally ordered, each event must be an 
indivisible operation. This means that all gate passages making op an event occur, at least 
in a conceptual sense, in parallel and simultaneously. In particular, it means that -a process 
may not pass through an enter gate unless it can pass through atf«f the enter gates for the 
given event class whose qualifying predicates are satisfied by to parameters. Only when all 
the entry conditions oh these gates are satisfied roaf the eater event, in the form of the 
parallel passage through aN these gates, take place. 
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As before, the processes that are blocked at a given enter event class are queued up in 
FIFO order. However, they need not be unblocked in this same order. Each process in the 
queue is waiting on one or more conditions, depending upon which qualifying predicates on 
gates apply to the activation. The process that proceeds first is the one closest to the front 
of the queue for which all entry conditions are satisfied. This may not be the one at the 
head of the queue, since that process may be waiting at a different set of gates than other 
processes further back in the queue. 

It is important that the distinction between qualifying predicates and conditions on 
gates be clear. A qualifying predicate can be attached to a gate of any event class, and 
represents a constraint on the parameters of the associated procedure activation. If the 
predicate is satisfied for a particular activation, then the process making the activation 
passes through the gate, while if it is not satisfied, the process bypasses the gate. A 
condition, on the other hand, applies only to an enter gate. This condition is on 
synchronization states, the current state and perhaps also one or more previous states. If the 
condition is true, then the process may pass through the gate. If it is not, then the process 
becomes blocked, and must wait in a queue for the condition to be true. 

As an example of a solution specification employing multiple gates, consider the 
abstraction discussed above with one operation h. Assume now, though, that h takes two 
integer parameters x and y. As before, activations of h for which parameter x is 
non-negative must be mutually exclusive. In addition, though, we want activations 'for 
which parameter y = 5 to be excluded whenever there is an activation currently executing 
for which y > x. The solution specification for this example consists of the following two 
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conditions: 

For gate [h(x.y) | (x > G)] ,n,,r : 

couiit([h(x.y) | (x .JS 0)r" ,,f ) * cputtOMta) 10c * ,0)]?*). 
For gate [h(x,y)|(y« 5)r' ,r : 

count<Ih(x^),| (y > xH-^^c^iiuaWx^ I (y > x)r M ) 

These conditions require two gates with entry conditions for event class h #n,#r , with 
qualifying predicates (x > 0) and (y - 5). There must be gates in both the h #w,-r and h M,t 
event classes to maintain counts for. the qualifying predicates (x £ 0) and (y > x). The 
abstract program for an activation of h with parameters x and y consists of: 
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h rcques1 : increment count(h rBqu • 8, ) by 1 
h en,er : in parallel, 

if (x > 0), wait until 

count([h(x.y> I (x > 0)] en,,r ) = count([h(x,y) | (x > 0)]""), 
and if (y = 5), wait until 

count([h(x,y) | (y > x)] enUr ) - count(th(x,y) | (y > x)r il ), 
and then in parallel, 
if (x > 0), 

increment count([h(x,y) | (x > 0)] en,er ) by 1 
and if (y > x), 

increment count([h(x,y) | (y > x)] ,Bter ) by 1 
execute body of operation h 
h exit : in parallel, 

if(x>0), 

increment count([h(x,y) | (x > O)]""'') by 1 
and if (y > x), 

increment count([h(x,y) | (y > x)] ex,t ) by 1 

That is, if both qualifying predicates (x > 0) and (y «■ 5) are satisfied for an activation, then 
both entry conditions must be simultaneously satisfied before its enter event. If only one 
qualifying predicate is satisfied, then only the entry condition corresponding to that 
qualified gate must be true. If neither predicate is satisfied, then the enter event can occur 
without delay. In any of these cases, count([h(x,y) | (y > x)]' n,er ) is incremented if and only 
if (y > x). 
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3.4 Semantics of the solution specification 

Thus far, the discussion in this chapter has retted on an informal, intuitive idea of the 
meaning of the solution specification. This section presents the formal definition of the 
semantics of solution specifications. As was the case for the problem specification language. 
whose formal definition was presented in Section 2£, the semantics of the solution 
specification structure are defined by specifying which histories are valid with respect to any 
particular solution specification. 

A qualification is a predicate on a vector of parameters. The domain of qualifications 
is denoted Q. One particular element of Q,is the predicate that always returns TRUE. By 
considering this special predicate to be the qualification associated with what until now has 
been called an "unqualified" gate, we are able to consider all gates to be qualified. So, a 
gatt is a pair <ec, q>, whose first component ec is an event class and whose second 
component q is a qualification. 

A state is a function from gates to non-negative integers. A state maps each gate into 
the count of the number of passages through it A conditions a predicate on a set of states. 
If the condition refers only to the current state, then the argument to the condition is a 
singleton set containing only the current state. When a condition refers to previous states as 
well, each of these states must also.be in the set. 
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A solution specification consists of a set of gates, and a condition on each one of these 
gates. (It is simplest to take the view that a solution specification assigns each request and 
exit gate, and every enter gate not explicitly given an entry condition, the condition that is 
identically TRUE.) The set of gates in solution specification ss is given by the expression 
Gates(ss). For every gate g e Gates(ss), the condition assigned to g in ss is given by 
Cond(ss, g). The set of previous states that the condition on gate g in solution specification 
ss refers to is given by PrevStates(ss, g). 

A history is valid with respect to a solution specification if for each event in the 
history, every solution specification condition that applies to the event is satisfied at the 
point in the history at which the event occurs. (Actually, only enter events have non-trivial 
conditions, but for the sake of uniformity, it is easier to define the concept in terms of all 
events in the history.) To define this formally, it is necessary to have functions that map 
histories into states, i.e. into functions from gates into counts. The function CurSt maps an 
object history, the sequence of events associated with a given object, into the current state of 
that object. Recall that an object history is either the empty sequence [ ], or else is obtained 
by adding an event onto some other history. An event is represented by a four-tuple of the 
form <p, t, n, a>, where p is the operation name, t is the event type, n is the activation 
number, and a is the vector of arguments. The definition of CurSt is: 
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CurStO - . Afo.ql.Q, 

Ci«St<add<h» «p, t, n. **) - X (ec, q). (if<p, t> «ee a q£*> 

then (Cur$t(hKec,q)*i) 
else purSt(h)(ec,q)) 
The notation used here is taken from A-calculus. The formula ^ (*, y^F" represent* the 
function of arguments x and y whose body is given by. F. 

The function MosRecSt (Most Recent State) maps an object history and a gate into the 
state of an object at the time of the roost recent event at that gale 
MosRecSttf I <ee,o,>) - X (ec, q), 

MosRecSt(add(h, <p, t, n, a>X <ec, q>) - jf <p, t> - ec A q<a) 

then CurSi(h) 
else MosRecSt(h, <ec, q>) 
The current state after history h becomes the most recent state for any gate that applies to 
the event added onto h. 

It is now possible to formally define the validity of a history h with respect to a 
solution specification ss. This is given by ValidSS(h, ss), where. 
ValidSS([ I ss) - TRUE 
ValidSS(add(h. <p, t, n, ■>), ss) - ValidSS(h, ss) a 

V (ec, q) (<ec, q> € Cates(ss) a ec - <p, t> a q(a) 

> SatSS(h, s%, <ec, q>) 
SatSS(h, ss, <ec, q>), defined below, is a predicate that determines whether the state 
represented by history h satisfies the condition in solution specification $$ for gate <ec, q>. 
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Thetcfoie, the definition of ValidSS simply states that a history is valid with respect to a 
solution specification if it was valid before the last event occurred, and if the history 
satisfies the conditions for all gates that apply to the last event. 

The predicate SatSS is easy to define. A history satisfies a condition simply if the 
current state plus the relevant most recent states of the history satisfy the condition. Recall 
that the condition on gate g in solution specification ss is given by Cond(ss, g), and that this 
condition is simply a predicate on a set of states. Formally, then, 
SatSS(h, ss, g) = C(States), 

where C = Cond(ss, g) 
and States = {CurSt(h)} U {MosRecSt(h, g') | g' € PrevStates(ss, g)} 

The subject of the next chapter is the method for deriving an equivalent solution 
specification from a problem specification. Section 4.6 justifies the method presented. This 
justification relies on both the formal definition of the problem specification language given 
in Section 2.6, and the formal definition of the solution specification in this section. 
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Chapter 4 
Derivation of the Solution Specification 

4.1 Introduction 

The subject of this chapter is the algorithm for analyzing a problem specification and 
deriving from it an equivalent solution specification. There are two aspects to the 
construction of a solution specification. Identifying the gates required in the solution 
specification is relatively straightforward. This simply involves identifying the event classes 
appearing in the problem specification. For qualified gates to be identified correctly, 
however, this must be done after all argument constraints have been incorporated into the 
ordering clauses of the specification, as explained in Section 4.5. 

Constructing appropriate conditions to attach to the gates associated with enter event 
classes is the formidable task. The algorithm for constructing these entry conditions is the 
subject of this chapter. As explained in Chapter 3, the set of conditions on all enter gates is 
sufficient to represent the complete solution specification. The other gates in the solution 
specification and the saving of previous state information are indicated implicitly by the 
quantities appearing in the entry conditions. 

In constructing a condition for an enter gate, the basic strategy employed is to 
determine, in terms of the synchronization state, what distinguishes points in a computation 
at which an event at that gate should or should not occur. "Should occur" here can be 
interpreted formally as satisfying the predicate Sat, which was defined in Chapter 2, relative 
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to the given specification. In making this determination, it is necessary to consider all 
relevant subsequences of histories, specifically those, subsequences containing the events 
mentioned explicitly in the specification. Each of these subsequences, or "orderings", can be 
classified as either valid or invalid with respect to the specification. *t each point in aih 
ordering at which an event occurs at the gate in question, it is possible to characterize the 
synchronization state. These individual characterizations can then be combined 
appropriately, based on the validity of the orderings, to form an overall condition for the 
gate. 

The paragraph above summarizes the main phase of the derivation algorithm. The 
result of this phase, which is presented futty in Section 4J2, is Ihe derivation for each gate of 
a "preliminary condition". For cases where the correct condition for a gate can be expressed 
solely in terms of the current state, the preliminary condition is correct When this is not so, 
the preliminary condition can be refined by iterating over another phase of the algorithm. 
This phase, which is presented in Section 4.3, uses information saved at previous states in 
the orderings as well as the current state. Section 4.4 contains an example of applying the 
algorithm of Sections 4.2 and 4.3. The one other aspect of the algorithm is some initial 
processing designed to make the specification suitable for analysis. Section 45 describes this 
processing, in which argument constraints are incorporated into the specification so that the 
transformed specification consists entirely of ordering etauses. The algorithm is summarized 
in its entirety in Section 4.6, and there a justification is presented for why it works. The last 
section of this chapter. Section 47, discusses the class of specifications for which the 
algorithm fails. 
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An important feature of the approach to be presented is a property that I call 
extensibility. This means that the algorithm can be applied to each conjunct in a problem 
specification individually. If the specification s is of the form 

Sj f\ $2 A ••• A s ny 
then for each conjunct Sj of the specification, the algorithm derives one or more conditions 
for gates in the solution specification. For each gate, the condition required for the entire 
specification s is simply the conjunction of the conditions obtained separately from the 
conjuncts s^. This property can be proved in terms of the formal semantic definitions of the 
problem specification language and the solution specification. Informally, it is true because 
each conjunct in a specification represents a separate constraint that must be met by any 
valid history, so that the overall specification represents a set of constraints, all of which 
must be met. If each constraint is implemented by a different set of solution specification 
conditions, then the joint overall constraint must be implemented by conjoining all these 
conditions. This is because an event may validly occur only if it does not violate any of the 
individual constraints. For this reason, the analysis of specification s can take place on each 
relatively simple conjunct separately, rather than on the entire, more complex specification. 
With regard to any reference in this chapter to specification s, the reader should understand 
that s can represent a single conjunct that is being analyzed individually. 
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4.2 Tke derivation algorithm 

This section describes the essence of the derivation algorithm. It is assumed that the 
problem specification consists exclusively of ordering information, in that all clauses, as 
defined in Section 2.5, are ordering clauses of the form (ej =* e^, where events e| and e^ 
refer to procedure activations for which arguments are not listed. That is to say, there are 
no argument constraint clauses, nor are arguments explicitly given for any procedure 
activations. The conditions derived for the solution specification in this phase of the 
algorithm refer only to the current synchronization, state, and not to any previous states. 
When any of the preliminary conditions derived by this phase is inadequate, then previous 
state information must be used in order to refine it. The method for doing so is presented 
in the section following this one. 

The algorithm is presented here on a step-by-step basis. Each step first is described as 
it works on a general specification s, and then illustrated on a particular specification. The 
specific example used for illustration purposes is example A from Section 2.7, which will be 
denoted here as specification Sj: 

p .r«9U«t => q «*" 3 p**» =* q •*» 

As discussed in Chapter 2, the effect of this specification is to give executions of procedure 
p priority over those of procedure q. 
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Given a problem specification s, the first step in deriving the equivalent solution 
specification is to identify Evexp{s), the set of event expressions appearing in s. Informally, 
this set can be constructed simply by noting which event expressions are contained in the 
specification. The recursive definition of Evexp(s), which was presented in Section 2.6 and 
is repeated in Figure 4.1 below, can be used to lormaUy jcenstrutt Evexp(s) for any 
specification. For the example specification, 

Evexp(s,) - {p{«**« pf*", qjT " 

Once Evexp(s) has been constructed, the next step is to construct the set of possible 
time orderings among the events represented by these expressions. Suppose a history 
contains events that correspond to the event expnrwions in the specification. Formally, 
using the definitions of Section 2.6, this means that there is some interpretation mapping 
the event expressions in Evexp(s) into a subset of the events in the history. Then whether 
or not the history satisfies the specification under this, interpretation 4epends upon the 
order among exactly these events. To analyze all possible histories that involve events 
corresponding to the expressions in the specification, it is sufficient to analyze all possible 
subsequences of these events-. A subsequence of events in a history is called a sub*history. 



Figure 4.1. Definition of Evexp(s) 

Evexp(ej =* e 2 ) - I <^i . «2 

Evexp(expj rel exp 2 ) - { }, for rel € Rel 

Evexp(-- s) - Evexp(s) 

Evexp(sj op $2> - Evexp(sj) U Evexp^), for op € Op 

Evexp(3 x (s)) - Evexp(s) 

Evexp(V x (s)) - Evexp(s) 
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Since each relevant event is represented by an event expression appearing in 
specification s, the sub-histories of interest correspond to the possible sequences of the 
expressions in Evexp<s). Each sequence of event expressions that represents a possible 
sub-history is called an ordering. Every history containing events represented by the event 
expressions of Evexp(s) corresponds to exactly one of the dfdermgs. 

If the size of Evexp(s) is n, then there are n! permutations of these n events, but not all 
of the corresponding sequences are necessarily possible time orderings. To be a possible 
ordering, a sequence must obey the bask: constraint 

u m u m u m • 

for every procedure activation u m . For example, consider a case where 

Evexp(s) « {x a "*~\ x«~; x a « rt , ■%—"*, y^, 75-*}. 

While there are 720 permutations of these fix events, only 20 sequences represent possible 

time oi^erings. An additional constraint that must be met by any ordering is that 

(m < n) D <u m , ^ w,, **> u n mm ^), 

since the numbering of procedure activations is based on the order of the respective request 

events. Thus, for a specification in which x^^^iii^i^^^^bofh appear, X J**™* must 

precede x i+ | r,<,u * s * in every ordering. These constraints are exactly the ones embodied in the 

predicate Possible defined in Section 2.6. Ruling out all orderings that are impossible 

corresponds to restricting attention to object histories that are possible according to that 

definition. 
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Formally, the construction of the possible orderings among the elements of Evexp(s) 
can be carried out in two stages. The first stage consists of generating all permutations of 
the elements of Evexp(s). Then every permutation that violates one of these basic 
constraints is eliminated. 

For the example specification Sj, Evexp(sj) contains three events, as already noted. 
Although there are six permutations of these three events, only three are possible time 
orderings, since the other three violate the constraint that p/"'** 8 ' =» pj enUr . These three 
possible orderings are: 



(1) p i rH ' urtt => Pi en,er => q: enUr 



(2) pfws* => q •»*•' =» p™'" 

(3) q •"♦•' =» p . request ^ p . enter 

That is, in any possible history in which there are events corresponding to the three event 
expressions in Evexp(sj), these events must occur in exactly one of these three orders. 

Once the possible orderings of the events associated with specification s have been 
constructed, it is necessary to separate them into two classes. Those that satisfy the 
specification s are termed valid orderings, while the rest are invalid. Validity of an 
ordering with respect to a specification s can be determined by simply evaluating the 
formula s. In this evaluation, either TRUE or FALSE is substituted for each expression of 
the form (ej ==» e2), depending upon whether or not event ej precedes event 62 in the given 
ordering. Since it is assumed that by this point the specification consists entirely of 
ordering information, the result of this evaluation must equal either TRUE or FALSE. 
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The ordering is valid when the formula evaluate* teTRLJE; and mvalid when it is FALSE. 
In terms of the format temaptks^ th^prabtem Jpecifiutionfatngaage presented in Chapter 
2, this corresponds to evaluaHhg the predicate Sat for an Otherwise valid history that 
contains the given ordering as a sub-history under an arbitrary interpretation. 

For the example, substitution of ordering (0 into specification sj yietts the formula 

TRUElsTfcUE, i 

which evaluates to TRUE $ub«ituting ordering W into Sj results in the formula 

FALSE D FALSE, 
which also evaluates to TRUE. Orderings (1) and (3) are therefore both valid with respect 
to sj. Substituting ordering (2) into Sj, however, yields 

. TRUED FALSE, 
which is FALSE, so ordering (2) is invalid. 

In describing the next step of the algorithm, some definitions are needed. A prefix of 
a sequence is simply any initial subsequence. A special case is the empty sequence, which is 
a prefix of every sequence. Any two sequences have a unique longest matching prefix which 
they share. Given two different orderings of n events, there is a unique k, where < k < n, 
such that each of the first (k - I) events in the two orderings are identical, and the k-th 
events differ. The shared prefix of length (k - 1) is the longest matching prefix of the two 
orderings. 
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It is necessary to compare each invalid ordering with all of the valid orderings in turn. 
In each case, there will be a longest matching prefix that the two orderings share, which 
may be the empty sequence. Of all these longest matching prefixes, we choose the one with 
the greatest length. If this prefix is of length (k - 1). then the k-th event (more precisely, the 
k-th event expression) in the invalid ordering is the offending event of that ordering. The 
offending event is the one at which the invalid ordering first "goes wrong" in the sense of 
violating the specification. That is, it is at this point in the history that the Sat predicate is 
first violated for the specification. Assuming that the offending event is in an enter event 
class, a condition must be attached to the gate for that event class in the solution 
specification, so that the SatSS predicate for the solution specification is also violated at this 
point. 

If the offending event in the invalid ordering is not an enter event, then the 
specification is illegal, in that it does not agree with the basic guardian model being 
employed here. According to the model, only enter events can be conditional and sa be 
delayed from immediately taking place. If a specification implies that some request or exit 
event should be delayed, then it represents a property that is incompatible with this model. 
Such a specification cannot be analyzed by the method presented here. (These cases are 
discussed in section 4.7.) 

Returning to the example specification Sj, ordering* (I) and (3) have already been 
shown to be valid, and ordering (2) to be invalid. For orderings (1) and (2), the longest 
matching prefix consists of the sequence of length one whose only element is p i t,< ' u,8 V for 
orderings (2) and (3), the longest matching prefix is the empty sequence. The longest prefix 
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of ordering (2) that matches some valid ordering is therefore the one-element sequence 
[p.r.qo.stj. The offending event m (2) is the event immediately following this prefix, namely 
q «nt»r Yhui a condition is required on the gate for the q*"** event class to prevent this 
invalid ordering. 

In the general case, a condition must be derived for each event class that contains an 
offending event in one or more invalid ordering*. When this condition is placed on the 
gate for that event class in the solution specification, it mutt prevent any sub-history 
corresponding to one of these invalid orderings, but allow any of the valid orderings as 
sub-histories. The derivation of the condition requires the state, i.e. the synchronization 
state of the object, to be characterized for each invalid ordering at the point at which the 
offending event occurs, so long as the offending event belongs to the given event class. The 
method for characterizing the state is explained below. A disjunction of these state 
characterizations is formed, to be denoted here as Dj. Dj represents a general state 
characterization of when the occurrence of aft event in the given event class would fail to 
satisfy the specification. Similarly, the state must be characterized for each valid ordering at 
the point at which an event in the class occurs. The disjunction of these characterizations is 
denoted D v , which is a general characterization of when the occurrence of such an event 
would satisfy the specification. 

The expression given by the formula (D y a (-> Dj)> represents a preliminary possibility 
for the condition required in the solution specification. The term (^ Dj) guarantees that the 
expression is strong enough to exclude every invalid ordering. Conjoining the term D v 
aids in the simplification of the formula. Since any conditions that are trivially true in all 
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orderings of interest appear both in D v and in>D t , such conditions cancel out in the 
conjunction of D v with the negation of Dj. These conditions may arise from the fact, for 
instance, that at the point just before an event in the p** v class occurs, it is always true that 
count^'"" 1 * 8 ') > count(p' n,w ), since there is at least one activation (the one under 
consideration) for which the request event, but not the enter event, has occurred. Thus, 
this clause is a component of every state characterisation, whether the ordering is valid or 
invalid. The conjunct D v guarantees that the negation of this clause is eliminated from the 
condition. 

The preliminary condition given by (D v a (-> Dj)) is known to be at least as strong as 
the condition required* since the term (-• Dj) exclude* *# invalid orderings, i.e. all histories 
with sub-histories corresponding to an invalid ordering. The condition must be tested 
against all the valid orderings,, however, td check that it is weak enough to allow all of them 
as sub-histories. This checking is accomplished by^ determining that the condition is 
satisfied at the point at which the appropriate event occurs ih each valid ordering. If the 
condition is satisfied at all these points, then the -condition is correct, and the task is 
completed. If this is not so, then the condition is too strong; in that it rule* out some 
orderings that are valid according to the specification. When this happens, steps must be 
taken to refine the condition by weakening it appropriately. This weakening process will be 
described in the next section. 
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In cha racterizing the synchronization state of the object at * point in an ordering, the 
ordering must be considered to represent a subchistory that i* embedded withm some 
possible history. Except for what can be deduced from the. ordering itself, nothing can be 
assumed about the history or about the interpretation by which the event expressions hi t**e 
ordering are mapped into the, events in the histwy. There may be a» arbitrary number of 
events in the history preceding the sub-history, and between any two events in the 
sub-history. It is known, however, that the history it-possible. Also, the history can be 
assumed to be compatible with the solution specification structure, since if it is not, then the 
algorithm cannot succeed in any case (see Section 4.7). 

The characterization of the state *herefbre relies entirely on the other events in the 
sub-history represented by event expressions in the ordering. Since the characterization 
involves actual events in a history rather than 4he event expressions in an ordering,, each 
event expression conceptuaMy i$ replaced by a real event, so .that every variable within an 
expression is replaced by an actual value. Since the interpretation for making these 
replacements is arbitrary, however, nothing can be assumed about the values. All that is 
known is that for any given history and interpretation, there is some particular value for 
each variable. For this reason* in the state characterization each variable is existentially 
quantified, That is, every state characterization formula isof the form 

3(i, « m )(S), 

where {ij, ... , i m } is the set of variables appearing free in formula S. 
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The body S of the state characterization formula consists of placing bounds on the 
counts of event classes, based on which of these events occur before and after the point at 
which the characterization is being made. It is assumed that the characterization is made 
just before the enter event of interest occurs, so that this event itself has not yet taken place, 
but every preceding event has occurred. The characterization contains a clause 
corresponding to each event in the ordering, that is, to each element of Evexp(s). For each 
e € Evexp(s), the count of the event class containing e is given either a lower bound if e 
occurs prior to this point in the ordering, or an upper bound if e occurs subsequent to this 
point. The bound in either case is the invocation number of e. 

For example, let e be the event expression x rn ,n,,r . If event, x n) " n,,r occurs prior to the 
enter event in the ordering being considered, then the state characterization contains the 
conjunct 

count(x ,nUr ) > m. 
The reasoning is that if x m ,n,,r has already occurred, then so have each of Xj c ,nUr for (1 ^ k 
< m), so that count(x ,nt,r ) is at least as great as m. The count may be greater than m, as 
other events in the x' n,,r class may have taken place in between event x m * nUr and the 
current point, but it is not less than m. On the other hand, if x m * nt,r occurs after the point 
at which the characterization is made, then the clause becomes instead 

couiit(x ,nUr ) < m. 
If x rn ,n,,r has not yet occurred, then neither has x k ,nUr for any k > m, so that count(x* n,#f ) 
must be less than m. Again, other x ,n,,r events may occur in between the point of the 
characterization and x m ,n,,r , so that the count may be less than (m - 1), but it is certainly 
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less than m. 

This method of state characterization relies on a first-come-first-served scheduling 
discipline at each gate. That is, it assumes that any history occurring prior to event x m * nU '' 
contains exactly 

lx l - x 2 x m-l J 

as the subsequence of events occurring at the x en,,r gate. This scheduling policy is built 

into the structure of the solution specification, and so it may be assumed that if a correct 

solution specification can be derived for a specification, then it must fit this structure. 

There are specifications with which this first-come-first-served scheduling policy is not 

compatible, and the derivation algorithm fails to derive a solution specification in such 

cases. This point is discussed more fully in Section 4.7. 

Since every state characterization formula is of the form 

3(ij i m )(S), 

the construction and manipulation of the formulas D v and Dj must make use of logical 
properties of existentially quantified expressions. Because of the negation of Dj in the 
preliminary condition, universally, quantified expressions must also be manipulated. A 
summary of the important logical properties used for simplifying these formulas appears in 
Figure 4.2. Properties (El) through (E6) are equivalences applicable to existentially 
quantified expressions, and properties (Al) through (A6) are their dual forms for universally 
quantified expressions. (QI) and (Q2) apply to formulas involving both types of quantifiers, 
and (Dl) and (D2) are the distributive laws for A and v. 
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Figure 4.2. Logical properties of quantified expressions 

(El) 3 i (S,) v 3i(S 2 ) « 3i(Sj v S 2 ) 

(E2) 3(i,j)(A(i) a B(j)) « 3i(A(i» A 3j(B(j» 

(E3) 3<i,j)(A(i)) « 3i(A(i» 

(E4) -<3i(S)> « Vi(-S) 

(E5) 3 i (x > i A y < i) « (x > y) 

(EG) 3 i (x < i) « TRUE 

(Al) V i (Sj) a V i (S 2 ) ♦♦ V i (S, A S 2 ) 

(A2) V(i,j)(A(i) v B(j)) « Vi(A(i)) v Vj(B(j)) 

(A3) V(i.j)(A(.)) « Vi(A(i)) 

(A4) -(Vi(S)) « 3i(-S) 

(A5) V i (x < i v y > i) « (x < y) 

(A6) V i (x > i) « FALSE 

(Ol) 3 i (S) A V i (- S) » FALSE 

(Q2) 3 i (P a S) a V i (Ct v - S) » 3 i <P A Q A S) 

(Dl) ((x A y) v z) « ((x V z) A (y V z)) 

(D2) ((x v y) a z) ** ((x a z) v (y A z)) 



Let us return to the example for an illustration of the above discussion. Recall that 
the offending event in the invalid ordering is qj en,er , and so a condition must be derived for 
the q enter gate. In ordering (1), the event q: en,er is preceded by events p/"^ 8 ' and pj' n,,f , 
and has no events following it. Therefore, the state characterization cj is: 

3 (i,j) (county 068 *) > i a count(p en,,r ) > i a count(q en,er ) < j), 
where the first two terms in the body are obtained from the events preceding q; ,n *', and the 
last term from the fact that qj 9n,er itself has not yet occurred at the point at which the 
characterization is made. In ordering (2), the event qj en, * r is preceded by p^ * 8 ' and 
followed by pj Cn,er , so the state characterization c 2 is: 

3 (i,j) (count^"""" 8 ') > i A count(p" r,,er ) < i a count(q entQr ) < j). 
In ordering (3), qj en,er precedes both p/ 6 " * 8 * and p i enUr , and the state characterization c 3 is: 
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3 (ij) (count^ "*)^ i ^.^m^kf^^^^fP^W^^^- 

These individual characterizations can now be combined to form the terms D v and 
Dj. The disjunction for the valid ordering; D v is equal to (cj v cj), or 

«count(p r,,p * s ?> i J a count(p ,n,w ) > i) v 
(countV** 8 *) < i a count(p w,,,r ) < i»). 
The disjunction for the invalid orderings Dj is simply C2» so that (-» Dj) becomes 

V (i.j) <count(p r *' ort, > < i v countCp*"^) > i v countCq"**') > j). 
The formula for the preliminary condition is therefore given by D y A '(" Pp, or 

3 (i,j) (count(q'" tor ) < j a 
((cou»it(p r,,uW< ) > i a count(p* Btar ) > i) v 
(count(p , • < ^ ,s, ) < i a count(p* ,,,,r ) < i)» a 

V (i.j) (coullt(p re< ^• s, ) < i v count(p• n, • , ) > i v count(q" nUf ) > j). 

This formula can be simplified. Since the terms involving i and j are independent in 
both of the quantified expressions, they can be separated, using logical properties (E2) and 
(A2) from Figure 4.2. Thts yields the formula: 

3 i ((«>unt<p ,, ** rt ) > i a c«ttit<p* rt *) > i) v 

(count(p f#qo,s ') < i a comrtfo"*") < i)> a 

3j<«oant<q w * ,, )<j> a 

(Vjtcournlq^fcj) v 

V i <count(p r •*** , ) < i v count(p , "* w ) > i». 
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By distributivity property (D2), this is equivalent to 

(3 i ((countfp"** 8 ') > i a countip*"^ i i> -v 

(count<p f •*'• 8, ) < i a «wnKp' n, ^<i)) a 

3 j (counKq"*") < j) a 

Vj<count(q-* w )>j)) 

v 

(3 i ((coullt(p w, ' u • 8, ) > i a couiit(p ,Mw ) > i) v 

(count(p ,w ' 0,8, > < i a cou«t<p ,M ") < i» * 

3 j (count(q' n,w ) < j) a 
V i (count(p r • qo • g, ) < i v countfp"""*) > i)). 
The first disjunct is simply FALSE, since it contains the conjunction of 

3 j (count(q Mtor ) < j) 
and 

Vj(count(q ,n, ")2:j). 
This means that the formula reduces to the second disjunct, 

3 i ((count(p r,q00 ') > i a countfp""") > i) v 

(counKp'-"^') < i a count(p• n, ' , ) < 0) a 

3 j (counKq"*") < j) A 

V i (counKp-'"'''"*) < i v county*"*") > i). 

Each of the first two conjuncts simplifies to TRUE, so the entire formula reduces to 

V i (count<p , •« u •• , ) < i v count(p wUr ) > i), 
which is equivalent to 

counKp^""* 1 ) < count<p w,,r ) 
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by property <A5). Using the a priori fact that «owit<|tf**^) £ ttiii»t(p f ^& the preliminary 
condition can be simplified finally to: * L 

coUhtd^W* 1 ) - count 



To determine whether the preliminary condition is indeed correct and not overly 
strong, it is necessary to test it at the appropriate point in each of the valid orderings. The 
valid orderings are (1) and (3). At the point of event qf^ in each of these orderings, the 
condition 

is satisfied, showing that it is weak enough to permit both valid orderings. Because of the 
conjunct (-■ Dj) in the condition, it ii guaranteed to be strong enough to prevent the invalid 
ordering. Therefore, it is exactly the condition required for gate q"**', and a correct 
solution specification has been constructed. 

4.3 Use of previous states 

In the example presented in the last section, the current state alone was sufficient to 
derive the condition required in the solution specification. The purpose of this section is to 
explain the method employed when this is not the case, and one or more previous states 
must be used as well. Information from previous states is used to refine a preliminary 
condition that is too strong so that one or more valid orderings do not satisfy it. 
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An overly strong preliminary conditio* is weakened by disjoining one or more terms 
to it. The new condition that results is strictly weatefthan tto^reiirnmary condition, since 
it is the disjunction of the preliminary condition antfother terms. All valid orderings that 
satisfy the preliminary condition therefore automatically satisfy the new condition. The 
purpose of the weakening terms is to include the remaining valid orderings as well. For 
this reason the analysis for constructing a weakening term can disregard the valid orderings 
satisfying the preliminary condition. Only the remaining valid orderings not permitted by 
the preliminary condition need be considered, along with all invalid orderings for which the 
event in question is the offending event. 

Each weakening term shares the property with the prettriWhary condition that it is at 
least strong enough to exclude every invalid ordering. Therefore, all that need be checked 
for each weakening term is which valid orderings that have thus far been excluded are 
permitted by the given term. The method terminates when the condition is weakened so 
that all valid orderings are allowed, or else when no further weakening terms can be 
constructed. 

In deriving a weakening term, it is necessary first to find some event that precedes the 
enter event in question in each ordering being considered, i.e. all of the valid orderings not 
satisfying the preliminary condition plus all of the invalid orderings in which the enter 
event is the offending event. This event may be in any event class, and is not limited to 
enter events. Once such an event is found, the weakening term is constructed in much the 
same way as the preliminary condition, but using state characterizations at this previous 
event. The state is characterized at the point of the preceding event in each of these 



-82- 

orderings (but not in any of the other valid orderings). Notice that each of these 
characterizations, rather than involving ordinary counts of event classes, concerns quantities 
of the form [count(ec) e g], i.e. counts of event classes saved at the event at gate g. 

At this point the characterizations from the valid orderings are disjoined to form a 
new expression D v \ and the characterizations from the invalid orderings are disjoined to 
form Dj\ The formula (D v ' A (-> D^)) is constructed and used as a weakening term by 
disjoining it to the preliminary condition to form a new condition. This new condition is 
tested to determine whether the valid orderings excluded by the preliminary condition are 
allowed as a result of the weakening term. If all these orderings are permitted by the 
weakening term, then the new condition constitutes the solution specification condition. 

If there are still some valid orderings not allowed, then the process is repeated on the 
valid orderings still excluded. Here, however, each characterization refers to both the 
current state arid the previous state. That is, each characterization involves both current 
counts and counts in the previous state. The weakening term (D v ' A (-• Dj')) is formed in 
the same way. This term is again tested on the excluded valid orderings, and disjoined to 
the condition if it is satisfied by any of the excluded orderings. 

For example, consider the specification 

(Pi"" => Pj' n,,r ) => 
3 k (pf** => q k ,n,,r =* P j ,nUr ). 
When the preliminary condition is formed for gate p* n, " f , it is found not to satisfy the valid 
ordering 
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A weakening term mast therefore be constructed "far this ordering. The two invalid 
orderings are 

(2) p^^p**"**^**** 

<3) q^ ■** pf** =» pf** ' 
in both of which the offending eyent is ©j*"**.' The-bfie event that precedes pj ,nUr in each 
of these three orderings is p* M . The state characterization a¥thls%vent in each of the 
three orderings is: 

c,: 3<i.J.k)([count<p wri, )«p" ri, ]<i a [count(q"" Ur ) • p' xi, 3 < k 

a [count<p ,n *>9p" i, ]<j) 
c 2 : 3 (i ,j. k) ([eounl(p Mi ') • p mM ) < i A [countdf"^) • p** H J < k 

A [cOUIlt(p'* , * r ) 9 p'"*) < j) 

c 3 : 3 (i, j, k) <[count<p ,xH ) « p Mit ] < i a [count<q M,,r ) • p""] > k 
a [count(p ,n,,, > • p' x "] < j) 
However, the formula (D v ' a (-• D 4 ')) given by 

Cj A (- (C2 v c 3 » 
is equivalent to FALSE, which is obviously useless as a weakening term. 

Therefore, it is necessary to form new characterizations of. berth the current and 
previous states. These are given by: 

c{: 3 (i, j, k) <count(p' xi ') > i a couiit(q ,n,,r ) > k A count(p* nUr ) < j 

A [county 8 "'*) 9 p" xit ] < i a [count<q ,nt#r ) 9 p' xi1 ] < k 

A tcount(p ,n,,r > 9 p M *] < j) 
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c 2 ': 3 (i, j, k) (count(pf^) i t ^Wtvm^^^K &, A count(p• ,rt • , ) < j 

a [count(p" H )«pV^^ 

a [county*"'") •?•**]<# 
c 3 ': 3 (i, j. k) (countfp* 1 *) fcO- /***»»&(»*#) £ * A count(p*" , ' r ) < j 

a tcount(p*"%» pT^ < * -A fcortrtC^f^ • p***] > k 

The new weakening term <D V ' a (-- Dj')) is equal lo ,, 

c,' a (- (c 2 ' v Cj*)), 
which simplifies to f "; 

couBt(q" Mw ) > [co*nt(q ,n,,f > ■ p«* a 3, 
which does satisfy ordering <i). As a result, the K>UittOA >p«ctf»cat4on condition is given by 
disjoining this term to the preliminary condition. ; 

If neither of the weakening terms obtained as a result of a given previous state is 
sufficient to include all of the remaining orderings, then another previous event must be 
found and the entire weakening process is repeated using the state at that event. Since this 
may involve using the next-to-most recent, etc event at a particular gate, a notational 
extension is needed to refer to such quantities, such as [count(ec) m g], etc 

The idea behind the method is to find some property that distinguishes the valid 
orderings from the invalid ones. Unless the specification is one that violates the underlying 
model, it is always possible to find such a property. A valid ordering that cannot be 
distinguished on the basis of the preliminary condition must differ from an invalid 
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oi dering by the exact ordering of previous events, rather than 1 by their absolute number. 
At some previous event, then, certain other events must have occurred in the valid ordering 
but not in the invalid one, or vice versa. Using the state at that point allows the two to be 
distinguished from each other. Using only the previous state allows a weakening term to be 
constructed that involves only the relationships among quantities at that previous event. 
When this is not sufficient to distinguish all valid orderings, then characterizing both the 
current and the previous state permits relations to be formed between current and previous 
quantities. 

The weakening process is repeated until one oflwo things happens. If every valid 
ordering is allowed, by either the preliminary concUtion, involving the current state or else 
by a weakening term involving some previous state as well, then a correct solution 
specification condition is thereby obtained. If instead, one or more valid orderings are still 
disallowed, and no event can be found that precedes the enter event in question in both the 
disallowed valid ordering(s) and all the invalid orderings, then the algorithm fails in 
constructing a condition. A discussion of situations in which the method fails will be 
postponed until Section 4.7. 

4.4 An example using a previous state 

This section contains an examplt of applying the algorithm as it has been presented in 
Sections 4.2 and 4.3. The example chosen is one for which the current state is insufficient 
for expressing the solution specification conditions, and previous states must be used. The 
specification to be analyzed here is example 7 from Section 2.7, to be denoted s^. 
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( a ..ntar ^ unto) „ ^ Wtoc _> d «*^ 

The first step in the derivation process is to identify the set of event expressions in the 
specification. The set of event expressions in this case is given by 

Evexp(s 2 ) - {a,'" 1 ", b J -" tar , cf*" t df**). 
The next step is to construct all possible orderings among these event expressions. In this 
example there are no two events associated with the same procedure activation (such as 
p. request and p .«nt.r) nor are there tWQ ^^ events f or lne ^me procedure (such as 
p.r«quest and p , ^«qo«st) Therefore any of the 24 permutations of the four events in 
Evexp(s 2 ) represents a possible ordering among them. These 24 orderings are Msted in 
Figure 4.3 and numbered for the sake of future reference. 

Each of the constructed orderings is tested against the specification to determine 
whether it satisfies the specification and is therefore valid, or fails to satisfy it and is 
invalid. For example, in ordering (6), (a^" => bj ,ntor ) and (e 1 ,ntar ==> dj* nt,r ) are both 
FALSE, so that specification $2 evaluates to the expression 

FALSE ♦♦ FALSE, 
which is equal to TRUE. Ordering (6) therefore satisfies the specification. When the 
specification is evaluated for each of the first 12 orderings, it evaluates to TRUE, showing 
each of these orderings to be valid. Each of the last 12 orderings causes s to evaluate to 
FALSE, though, so that these orderings are invalid. 
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Figure 4.3. Possible ordering* for specification Sn 

(I) a .•"»•' => b: en,er =* Cj en,,r => dj enter 

/o\ -enter >, enter x u enter _v j enter 

(3) ai en,er => c i en,er =* dj enter => bj en,er 

(a\ u enter — ^ enter >, j enter __x enter 

(5) bi en,er =* dj en,er => ai en,er => Cj en,,r 

(6) bj en,er => d| en<er => Ci en,er =* a i wUr 

(7) c i en ''" => dj* n,er => aj en,er => bj en,er 

(8) Ci en,er =* aj en,er =* dj en,er => bj en,er 

(9) c .*nt.r ^ ^enter _^ -enter _^ d enter 

(10) dj en,er => c i en ' er ==> b: en,er =» aj en1er 

(II) d j en, «"' =* bj <,n,er =* Ci ,ntof =» a i 8nter 

(12) dj enter =* b j en,8r => aj en,er => Ci en,er 

(13) ai en,er =* bj en,er =* dj en,er => c i en,er 

(14) a i en,er =» dj en,er => bj en,ef =» Cj 9 "' 6 ' 

(15) a .«nt.r ^ d enter ^ c .enter _^ b enter 

(16). bj en,er =» ai en,or => Cj en, ' r => d: en,er 
(17) b: en,er =* Ci enler => d: en,er =» a™' 8 ' 

/i o\ l. enter >, f enter - _ enter _^ j enter 
enter », j enter v l. enter », _ enter 



(19) <;.•»"« ^ d enter ^ b enter ^ a . 

(20) Cj en,er => b: en,er =» dj en,8r => a i 8n,8r 

(21) c j en,er => bj en,e *' => ai en,er => dj en,er 

(22) dj en,er => Ci en,er =» a i en,er => bj en,er 

(23) dj en,er =» a i en,er => c i 8n,8r =* bj ,n,er 

(24) d. en,er => aj 8 " 1 " => b| en,er => Cj 8 "' 8 ' 
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The offending event in each in vaM ordering can be kttttttfied by comparing the 
ordering with, all the valid orderings to determine at what point the invalid ordering fWst 
fails to satisfy the specification. For example, invalid ordering 63) matches Valid ordering 
(I) as far as the first two events are concerned. Since this is flie longest prefix that does 
match the prefix of some valid ordering, the next event in (13), namely dj ,B,,r , is the 
offending event. When this is done for each of the 12 invalid orderings, it is found that the 
offending event is df nt9T in orderings (13) through (15), c i * M * r in (16) through (18), bj - "'" in 
(19) through (21), and ai ,nUr in (22) through (24). 

A condition is needed for each of the four enter gates mentioned in the specification. 
Here the condition for the a ,nUr gate will be derived. To determine the condition for this 
gate, it is necessary to characterize the state at event a i * rt * f in each of the 12 valid orderings 
as well as in each of the orderings in which it is the offending event, namely (22), (23), and 
(24). The characterizations one obtains for all of these orderings, using the characterization 
method described in the previous section, are listed in Figure 4.4, with characterization c^ 
applying to ordering i. 

The formula that is obtained from disjoining the characterizations cj through cj 2 is 
given by 

3 (i j) (count(a ,M,f ) < i A 

(<count(b ,n,w )<j a cwint(c ,rtw )^i) v 

(count(b ,n,,f ) > j A count(d' n **) > j) v 

(count(c ,n,,f ) < i a count(d* n,w ) < j)». 

This formula is D v , which represents a characterization of when the occurrence of such an 
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Figure 4.4. State characterizations at event if**** 

Valid orderings 

c,: 3 <ij) <count(a en,,r ) < i a count(b ,n,,r ) < j a count(c M,,r ) < i a coimt<d* nUr ) < j) 

c 2 : 3 (i.j) (coim^a*"**') < i a count<b^<-| A"co«nt<C i *^ r )<t a 0a*nt<d""* r ) < j) 

c 3 : 3 (i j) (count<a en, r) < j A counWf? r > < j A cou*t(cf^ r ) < i a eou*t(d• nt • , ) < j) 

c 4 : 3 (ij) (coMiit(a' n,,r ) < i a count(tf rt,r ) * j A c«M>tfc'" Ur ) ,< i a count(d" ,Ur ) < j) 

c 5 : 3 (i.j) (count(a" n,,r ) < i a count(b* n, * r ) > j A count(c" nUr ) < i a count(d* nUr ) > j) 

c 6 : 3 (i j) (count(a ,nUr ) < i a count(b wrtw ) > j a count(c wtof ) > i a count(d wUr ) > j) 

c r 3 (i,jMcotnitk ,n,,r ) oi a coniit(b ,n,,r ) < j a cownt(c M,f, )i i a eount<d ,nUr ) > j) 

c 8 : 3 (i,j) (count(a ,nUr ) < i a count(b• ,,, • , ) < j a count(c ,,rt,r ) > i a count(d ,n,,f ) < j) 

c 9 : 3 (i.j) (count(a" n,,r ) < i a count(b^) < j A cwwt(c , " ,,f > > i a count(d ,nUr ) < j) 

c, : 3 (i.j) (count(a ,n,,r ) < i a coujit(b ,nUr ) > j a cattOt(c• n, • , ) > i a count(d' nUr ) > j) 

c„: 3 (i,j) (count(a en,,r ) < i a count(b ,n,,r ) > j a count(c wrt ") > i a count(d ,M,r ) > j) 

c, 2 : 3 (i.j) (couiit(a ,n ' w ) < i a count(b ,n, * r ) > j a count(c wt " r ) < i a count(d M,,f ) > j) 

Invalid orderings 

c 22 : 3 (ij) (count(a' nUr ) < i a caunt(b ,n,,r ) < j a count(c M,,r ) > i A count(d ,nUr ) > j) 

c 23 : 3 (i.j) (count(a" nUr ) < i A count(b ,nt,f ) < j a cj>unt<c' M ' r ) < i a count(d ,nUr ) > j) 

c 24 : 3 (i.j) (count(a' nUr ) < i a count(b MUf ) < j a count(c• B, • , ) < i a count(d" nUr ) > j) 
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event satisfies the specification. The disjunction of c^. Cm, ,*nd Cg4 is Dj, representing a 
general characterization of when occurrence would not satisfy the specification. This 
formula is equal to: ^ . ../,,. . 

3 ; (i<j) (cauBtts*"^) < i a t^wtA**" 1 **)* j a c0^»t(a* ,, • , ) 2; j)> 
The body of 'this expression contains the three ;i *or^umts that appear In all <hree 
characterizations, whereas courttfc***') is greater than or equal to i in c^*j, *oiit less than i in 
the other two, so that these terms cancel out. 

The preliminary condition that one obtains then is given hf (D V :A (« D,)), which 
equals'" ".':•■' 

3(ij)(coant(a* Bfer ) i <i A 

((couiit(b* M l* f ) < j a couiit{c' lH * r ) i i) v 

(count{b* rt,, )£j a c©unt(d i *'*) > j) v 

(count(c* n,#f ) < i a count(d**'* r ) < j») a 

V (i j) (count(a ,n,,f ) > i v count<b #ntor ) i j v count(d #n,-f ) < j). 

The terms involving i and j in the universally quantified expression can b* separated. 

applying logical property (A2) from Section 4.2. This results in the formula 
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3 (ij) (eouiitUr'") < i a 
«count(b ,n,,r )<j a cotwt(c ,n, « f ) i i) v 
<count(b ,nUr ) £ j a count(d ,n ^) £ j) v 
(couBt(c w,w ) < i a count(d ,n, » , > < j))) a 

<V i (cpunt(a ,nUf ) i i) v 
V j (cou.Jt(b• n, • , ) > j v count(d wrt ") < j)). 
Using distributivity, this can be expanded into 

(3 (ij) (countta""") < i a 

((count(b^f)<| a couirt(c M,,r ) > i) v 

<count(b ,n,,r ) > j a cou^td^'") £ j) v 

(couJlt(c• n '• , ) < i a couttt(d' n,,r ) < A 

V i (count(a' nUr ) i i» 

v 

(3 (ij) (count(a ,n,,r ) < i a 

((count(b" nUr ) < j a count(c" M " r ) > i) v 

(couiit(b en,er ) > j a count(d* n, " r ) > j) v 

(count(c en,,r ) < i a cottiit(d ,n,,r ) < j))) a 

Vj (count(b , " u, )>j v count(d ,nUr ) < j)). 

The first disjunct reduces to FALSE, due to the conjunction of 

3 i <count(a" rt,r ) < i) 
and its negation. This leaves the formula 
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3 (i,j) (eount<a*^ *i ; A 

(counrXb'*^) > j a coimt(d*** , > > # v 

(count(c** ,,r ) < i a count(d• ,,ta, ) < a 

Vj (count(b""* ,r ) > j V s tf*M(d , " to, )<j). 
This can be simplified to 

V j (count(b w,Ur ) > j V cwflitfd* ,tar * < j), 
or simply 

countft""*) > countiEd"**) 
using logical property (A5). This ij the preliminary condition in simplified form. However, 
when one checks this condition against each of the valid ordering*, one finds that there is 
one ordering, namely (7), that violates the condition. This means that the preliminary 
condition is too strong, and must be weakened sufficiently so as to permit ordering (7). 

It is at this point that the weakening method described in Section 4.3 must be 
employed. An event must be found that precedes a i w,tar , the enter event in question, in 
ordering (7) as well as in each of the invalid orderings for which a^*' is the offending 
event, those being (22), (23). and (24). The single event that occurs before a i wrtw in all these 
orderings is dj Bn,,f . Thus, an attempt is made to find a condition at this event that 
distinguishes the valid from the invalid orderings. 
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The state characterization at d j""'" in ordering (7) is given by: 

3(i.j)([ea«nt(a ,n,#r )«d w,,r I<i a fe^ntCD**") • d w, *T< j a 
[countfc*"'") e d ,n,,f ] > i a [count(d* ntar ) • d M,,r 3 < j). 
Since all quantities refer to the state at the d*^ event, the notation "• d ,n,,r " is used on all 
counts. This becomes the term D v \ the disjunction of previous state characterizations for 
valid orderings. The characterization for each of orderings (22), (23), and (24) is the same, 
namely 

3 (i,j) <[couiit(a ,n,er ) e d ,n,,r 3 < i a [coutlt<b' n, • , a d""'"] < j a 
tcount(c ,nUr ) e d ,n »n < i a [<&irit<d*^Ta <&*"] < j), 
so the disjunction of characterizations Dj' is equal to this as well. The proposed weakening 
term is given by (D v * a (-> Dj')), which equals 

3 (i.j) <[count(a' n,,r ) e d« n,,r ] < i) a [count(b'"' ,r) • *"*'! < j a 

[count(c ,n,,r ) e d'"'"] > i a [count(d"" ,f ) • d ,ntar 3 < j) a 
V (i,j) ([count(a en,er ) a d ,nUr ] > i v [count(b" nUr ) a d ,n, ' r ] > j v 
[count(c" nUr ) e d"" Ur ] > i v [count(d ,ntar ) • d ,n, * r ] > j). 
Simplifying, this formula becomes 

3 i ([countta*^ • d**"] < i) a [countfc"*") • 4 M *1 > i), 
which reduces to 

[count(a ,n ' w ) • d"*"] < [count(c w,w ) • 6**1 
by logical property (E5). 
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When this condition is tested in ordering Vh k is found to be satisfied. Therefore, 
this term is disjoined to the preliminary cwdiucm?t04>btam the fu^solutkm specification 
condition: 

count(b ,n,,r ) > count(d ,n,,r ) v (cou*t<a #M,r ) • d w,#r ] ,*- [cou^|(c ,n,#f ) * d" Bto T. 

The method illustrated in deriving the condition for gate ***** must be applied again 
for each of the other gates b ,M * r , c witar , and d"^. Due to the symmetry of the specification, 
these derivations are completely isomorphic. 

4.5 Incorporating argument constraints 

The previous sections have presented the method for deriving a solution specification 
from the problem specification, under the assumption that each clause in the specification is 
an ordering clause of the form ej => e 2 , for some events ej and e^ When a specification 
also contains other clauses in the form of argument constraints, these constraints must first 
be incorporated into the ordering clauses of the specification before the algorithm described 
previously can be used. 

To simplify the discussion, it will be assumed that argument constraint clauses appear 
only as conjuncts in the hypothesis of an implication. A specification that dors not satisfy 
this condition can be transformed into an equivalent ow; that does as follows: Any 
specification can be put into conjunctive normal form (CNF) by well-known techniques of 
first-order logic. Each conjunct (which is analyzed separately, as explained previously) then 
consists of a series of disjuncts, some of which may be argument constraint clauses and at 
least one of which must be an ordering clause. The general form of such a conjunct is 
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therefbre: 

Nj v H% V ...- v fh v 0| v ... v O^, 
where each Nj is a (possibly negated) argument constraint clause and each Oj is a (possibly 
negated) ordering clause, antfj^Q and k£ .1. This Ottto^lNNtan^asing the tautology 
(x D y) » (-• x v y), into: 

((- N,) A (-- N 2 ) A ... A (-■ Nj)) 3 (O, v ... V O k ). 
In this way, all of the argument constraint clauses of the specification, some in negated form, 
are brought into the hypothesis of the implication, while all ordering clauses are in the 
conclusion of the implication. 

An argument constraint clause can involve either invocation number variables or 
arguments to procedure activations. When a cUuse involve* invocation number variables, 
it simply represents a constraint on those variable* appearing in the specificatioiv. This 
constraint must be incorporaji&'into eve#y state charactefaation. Otherwise, the clause can 
be ignored in the other steps of the derivation process. 

As an example, consider the first conjunct of the alternative producer-consumer 
specification of example 8 in Chapter 2: 

(i - j) 3 (depf x " ^ rem^ - '). 
The clause (i = j) is ignored for the moment, and the ordering clause is analyzed by the 
regular method. Of the two ordering* possible W the «tw?eve«ts to the conjunct, the 
ordering (dep^"" =» remj^ ,,r ) is valid* white the *tf»er order tog <remj W,, * f =» depj" M ) is 
not. The offending event is clearly remj^**', and a condition must be constructed for the 
rem" nt " r gate. The state characterization at event rem: ,ntaf in the valid ordering would be 
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3 (i j) (count(rem ,n,,r ) < j a counKdep""") > i), 
except that here the clause (i * j) must be added as a conjunct of the characterization, 
giving: 

3 (i j) (dMHrtfrari""?") < j a countfdep*^)^! v\ <i - j)X 
This expression represents D y . 

For the invalid ordering, the state characterization at event rem:*"*" also must include 
the clause (i - j). This formula is: 

3 (i,j) (count(rem ,n,,r ) < j A count<dep ,xi1 ) < i A (i - j)), 
which constitutes the formula Dj. The preliminary condition is D y A (-' Dj), or: 
2 (i j) <c©ttnt<rem' ,lU, > < j a eounKdep" 1 ^ Z J ■■ *v <i - j» a 
V (i j) (<»itnt(rem^ tof ) > j v c4*tiit(dep**) > i v (i * j)). 
When this condition is simplified, it reduces to: 

cow^rem*" 4 *) < comtt(dep*% 
which is the condition on the rem ,nUr gate required in the solution specification. This same 
condition is obtained when analyzing the specification 

depj"" => rem^*", 
in which the same property is specified, with the equality between the invocation numbers 
of the two activations indicated implicitly. 

This illustrates the genera* technique for handling relational clauses that involve 
invocation numbers. As it shows, such clauses are integrated in a- relatively simple manner 
into the method previously given for constructing a solution specification, since they simply 
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represent additional information that must be included in each state characterization. For 
predicates on arguments to procedure activations, the matter is not quite so simple. The rest 
of this section is devoted to discussing how to handle such clauses. 

An additional assumption that will be made concerning relations involving the 
arguments to procedure activations is that all such relations are made explicit. An example 
of an implicit relationship is a specification involving two procedure activations pj(x) and 
q:(x). Here the implicit relationship is that of equality of the arguments to the two 
activations. This can be made explicit by changing the argument of qj to some new 
identifier y, and adding the predicate (x - y) as a hypothesis of the specification. The 
situation would be handled in a similar manner if the argument to q; were not x but 
instead (x+1) or any other function of x. 

Argument constraint clauses are incorporated into the ordering clauses of a 
specification by qualifying all affected procedure activations. Once a clause has been 
incorporated by means of qualification, it can be eliminated from the specification, so that 
the result of the qualification phase of the algorithm is to transform the specification into 
one involving only ordering clauses. After this transformation has been accomplished, the 
specification contains some procedure activations that are qualified. Qualified activations in 
a specification result in a solution specification containing qualified gates. Specifically, a 
qualified gate is required in an event class for each event expression in that class appearing 
in the .specification and involving a qualified activation. The conditions required on all 
enter gates in the solution specification, qualified or unqualified, can be derived by the 
method already presented. In the derivation of these conditions, the qualifying predicates 
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on procedure activations are transferred to the associated gates. Both the enter gates for 
which conditions are constructed, and the gates on which counts are taken, may be 

qualified. 

The general form of a qualified procedure activation is: 

where v is the vector of parameters to procedure acttvayon p^ and C is some predicate 
involving these parameters and also- possibly some new variables tj through t m that do not 
appear in the specification. (The use of these "new f variables is explained below.) The 
qualifying predicate Q represents an implicit restriction on the universal quantification of 
the invocation number in* the expression, restricting i to those invocation numbers for 
which the corresponding activations satisfy condition C. This means that this event 
expression can only represent events whose arguments satisfy predicate C. 

Each clause that involves only the argument to a single procedure activation is 
incorporated into the specification by attaching the clause to the given activation as a 
qualifying predicate. For example, let vj be the vector of arguments to procedure p, and v 2 
be the vector of arguments to procedure q. Consider the following specification, where Cj is 
a predicate only involving Vj and C 2 is a predicate only involving V£ 

(Cj(v r ) /v C^r 2 )) & 
«p i (v,r» u,rt *=> q j <v 2 r«* f ) >(pj<v,r^ -«■» qf^r*")). 
Predicate Cj can be incorporated into the specification --by qualifying procedure activation 
Pp so that Pj(V|) becomes 

tPi<v f ) I C^v,)! 
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Predicate C2 can be incorporated by. qualifying activation q; t$ 

This transforms the specification itself to: 

([ Pi (v t ) \ C^vj)]^""* =* tqr i (v 2 ) \ C 2 <* 2 )F'• ,, ) D 
<[pi<v,) I Cj(v,)r Ur =* [q^^y^), 
The meaning of this specification is that any activation of p satisfying qualifying predicate 
Cj and any activation of q satisfying C 2 must obey the ordering constraint given, but other 
activations of these operations need not. This is exactly the meaning of the original 
specification: If Cj(vj) and C 2 (v 2 ) are both true, then the events must satisfy the ordering 
constraint in order for the history containing those events to be valid. If either of the 
qualifying predicates is not true, then the history is valid according to the specification 
regardless of the order among the events. 

In deriving a solution specification for this specification, there must be gates with 
qualifying predicate Cj(v,) in the p r • , l • s, and p wUr event classes, and a gate with qualifying 
predicate C 2 (v 2 ) in the q enUr event class. The entry conditions in the solution specification 
are derived just as if the activations were unqualified, except that the enter gates for which 
the conditions are derived, and the gates on which counts are taken, must be qualified 
appropriately. Without the argument constraint predicates, this specification would be sj, 
the example analyzed in Section 4.2, where the condition 

count^ 06 *) - count(p ,n,,, ) f 
was derived for gate q en,er . With the predicates included in the specification, the same 
analysis results in the condition 
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count<[p<vj) i c^ir***) .ewiHt<[p(v,) i cfrjir***): 

for the qualified gate [q(v 2 ) I C 2 (v2^* r - "Thirls, the qualification Cj(V|) on activation 
pj(vj) results in qualifying the gates p'"^" and p*'* mr , on which the counts arc taken, with 
this same predicate. The qualification C^yj) on activation q^vg) is attached to the q #n, * r 
gate for which the condition is derived. 

A predicate involving arguments to more than one procedure activation is converted 
into a conjunction of different predicates, each of which only involves the arguments to a 
single activation. This is accomplished by parameterizing the original predicate in terms of 
some new variable t. Once this is done, then the same method of qualification as discussed 
above can be used. For example, the predicate (x - y), where x and y are arguments to 
different procedure activations, is transformed into the two predicates (x - t) and (y - t). 
Each of these two predicates is then incorporated into the specification by using it to qualify 
the appropriate activation. 

As a result, the specification 

(x-y) D 
((p/x)^ "' =* q^yr'") 3 (Pi(x)' ft,,f => q j (y)* nl " r » 
is transformed into 

((x . t) a (y - t)) 3 

((p i (x) , • < ' o • s, => qj( y r ,,r ) z> (p^r'" => qj(yr ,#r )) 

by parameterizing the predicate (x - y). Incorporating the two predicates (x - t) and (y - t) 
into the appropriate procedure activations further transforms the specification into 
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([Pj<x) Kx«t)] r • ( ' u •» , =>{qj(y) Ny-or^) d 
(t Pi (x) | (x-Or'*' =» Eqj<y) I <y-t>r Ur > 
Since this is again simply specification Sj with qualifying predicates oh the procedure 
activations, the resulting solution specification contains condition 

o««nt<i^x) r(x-t)r^«V-<ottiit^i(xy Kx-«)r 8, * r ), 

for the qualified gate [q(y) | (y=t)] en,,r . 

The meaning of this solution specification is the following: For whatever value of t is 
equal to parameter y of an activation of operation q, the enter event for that activation 
passes through the gate [q(y) | (y=t)] ,n, * r . The condition for that gate is given by 

count([p(x) Ux-Or^ 0-8 ') - count([p(x) | (x-t)] 8 "'"), 
for this same value of t. Therefore, the "gate" [q(y) | (y-t)] actually represents an entire set 
of gates, one for each value of t, which is to say each possible value of y. 

An argument constraint predicate can always be parameterized into several predicates, 
each of which involves only the arguments to one procedure actrvatiom In fact, many such 
ways of parameterizating a given predicate are possible. For reasons having to do with the 
implementation that are discussed in Chapter 5, it is desirable that at most one of the new 
parameterized predicates be a non-functional relation between the activation parameters 
and the parameterizing variable(s), and furthermore that this possibly non-functional 
relation apply to the arguments of the activation whose enter event is the offending event. 
This restriction can always be followed in practice. 
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Once a predicate has been parameterized, the resulting predicates then can be used to 
qualify the corresponding procedure activations. When all predicates have been so 
incorporated, the specification consists entirely of ordering clauses involving qualified 
procedure activations. This specification can fee analyzed by the method presented 
previously, resulting in a solution specification containing qualified gates. 

4.6 Justification of the derivation method 

Both the problem specification language and the solution specification structure have 
been defined formally in terms of a common basis, the validity of histories. This means 
that the equivalence of a problem specification and the solution specification that is derived 
from it can be discussed in terms of the same set of histories being valid with respect to 
each. Rather than attempt a formal proof of correctness for the derivation method, this 
section will present an informal justification of the method. The justification will rely, 
however, on the formal definitions given for validity of histories. The complete derivation 
algorithm is presented in Figure 15, with the individual steps numbered for ease of 
reference throughout this section. 

In discussing the validity of histories with respect to both problem specification s and 
solution specification ss, we can refer to the definitions of the predicates Valid from Chapter 
2 and ValidSS from Chapter 3. They are repeated here 
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Figure 4.5. Derivation of solution specification ss from problem specification s 

(1) Transform s into a logically equivalent specification in which all argument constraint 
clauses are in the hypothesis of an implication and all ordering clauses are in the 
conclusion. 

(2) Parameterize each predicate on the arguments to more than one procedure activation 
into two or more predicates, each of which applies only to the arguments of a single 
activation. 

(3) Incorporate each argument constraint clause that applies to the arguments to a 
procedure activation by qualifying each appearance of that activation using the given 
clause as the qualifying predicate. The result is a transformed specification, to be denoted 
s'. Specification s' consists entirely of ordering clauses on qualified events, except possibly 
for clauses involving invocation number variables only, appearing in the hypothesis of the 
implication. These clauses are ignored until step (8). 

(4) Construct the set Evexp(s') consisting of all event expressions, including qualifying 
predicates, that appear in s'. The set of (possibly qualified) event classes associated with 
these event expressions represents the set of gates required in solution specification ss. 

(5) Construct all possible orderings of the elements of Evexp(s'), by generating all 
permutations of this set and then eliminating all those that are not possible. 

(6) Evaluate specification s' for each ordering, denoting each ordering that evaluates s' to 
TRUE as valid, and each that evaluates it to FALSE as invalid. 

(7) For each invalid ordering, find the longest matching prefix that it shares with some 
valid ordering, and identify the event following this prefix in the ordering as the offending 
event. If the offending event is not an enter event, then the specification is regarded as 
erroneous, and the algorithm terminates without being able to derive a solution 
specification. 

(8) For each enter gate (either qualified or unqualified) that applies to the offending event 
in at least one invalid ordering, characterize the state at each event to which the gate 
applies that appears in a valid ordering, and disjoin these characterizations to form D y . 
Also, characterize the state at each offending event in an invalid ordering to which the gate 
applies, and disjoin these characterizations to form D^. Any clauses in s' constraining 
invocation number variables must be included in each state characterization. 

(9) For each enter gate for which step (8) is carried out, form the preliminary condition 
given by (D y A --(Dj)). Test whether this condition is satisfied at every event to which the 
gate applies that appears in a valid ordering. If so, then the preliminary condition is the 
condition for that gate in solution specification ss. If not, then proceed to step (10). 
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(10) Find an event that precedes the given ent«f event in every valid ordering that is 
excluded by the condition so far, and also in every invalid ordering whose offending event 
applies to the given gate. 

(11) Characterize the state at each of these points, and form disjunctions D v ' and Dj' of these 
characterizations analogous to those formed in step (8). 

(12) Test all valid order ings still excluded to determine which satisfy the^term (D v ' a -<Dj')); 
If at least one such ordering does satisfy this term, disjoin the term to the current condition. 

(13) If some orderings still dfctiot satisfy the* condition, then repeat itep's (II) and (12) but 
using the characterisations bortv for the^rrew 

(M) Repeat steps <10) through (13) until either aH valid orderings satisfy the condition or the 
weakening term in step (18), of ho ptk*to&*?*M cMiltettam&M-'tityllfflyAf+te former; 
then the condition formed by disjoining 1 ** preftminary conditidrV and all the weakening 
terms from step (12) is correct and is attached to the gate in solution specification ss. If the 
latter, then the method fails to derive a solution spedfkationfer problem Specification s. 
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Valid([ I s) - TRUE 
Valid(add(h, e), s) - Va1id(h, s) A 

V (ee, f) (ee € Evexp(s) a f is an interpretation 
A Match(e, ee, f) z> Sat(h, e, s, f) 

ValidSS([ ], ss) - TRUE 

ValidSS(add(h, <p, t, n, a>), ss) - ValidSS(h. ss) A 

V (ec, q) (<ec, q> € Gates(ss) a ec - <p, t> a q(a) 

D SatSS(h, ss, <ec, q>) 
It is straightforward to compare these two definitions. They are both recursive formulas in 

which the basis case is the empty history [ ] and yields a value of TRUE. Also, both of the 

terms for the inductive case, which is add(h, e), are a conjunction of the given predicate 

applied to history h, and some term involving h and the last event e. Therefore, by 

recursion induction ([McC62]), the two definitions are equivalent if and only if these last 

terms are equivalent for all histories h and all events e - <p, t, n, a>. That is, it must be the 

case that 

V (ee, f) (ee € Evexp(s) a f is an interpretation a Match(<p, t, n, a>, ee, 

:> Sat(h, <p, t, n, a>, s, f) 

if and only if 

V (ec, q) (<ec, q> e Gates(ss) A ec ■ <p, t> a q(a) 

D SatSS(h, ss, <ec, q>). 

The first term requires predicate Sat to be true for all interpretations under which the event 

matches an expression in the specification. The second one states that for all gates in the 

solution specification "matched" by the event, predicate SatSS is true. These two terms must 

be equivalent for problem specification s and solution specification ss to be equivalent, in 
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the sense that they allow the exact same subset of possible object histories to be valid. 

Steps (1) through (3} of the derivation: method trahsform the original specification s 
into a new specification s'. To justify this transformation, it must be shown that 
specifications s and s' are equivalent with respect to ^h¥^VaW«^-p>eo^aie G yalid. which 

■■■ "'■■■ ■■>>'"< V » ~ ■.'•*. -■> ,l» i- ■■■-» .}W-<:,-- ■"'---■•'»- •:■ 

really means with respect to the satisfaction predicate Sat. Step (I), in which all argument 
constraint clauses are brought into the hypothesis of an implication simply involves 
properties of fine-order togk. Swp (2X*Ht *hic# predkites Involving argemems fcyifferent 
activations are parametrised. U alto mathematkalh 1( itrai g1i t ft»rwif d. 

To justify step (3), let us look at the transformation that it accomplishes. We start 
from a specification of the form QJv) D sj, where Q, is a qualifying predicate on some 
parameter vector v and Sj is some specification involving only ordering clauses. According 
to the definition of Sat, 

Sat(h, e. QJv) :> s,, f) - (Sat(h, e, Q{v), f) D Sat(h, e, S|, f)). 
Furthermore, Q, must be some combination of arithmetic relations, which are invariant 
under the Sat predicate, since 

Sat(h, e, expj rel exp^ f) - (f(exp,) rel f(exp 2 )). 
This means that if the interpretation of v by f satisfies the qualifying predicate Q, then the 
ordering specification sj must be satisfied by event e and history h under interpretation f. 
If Q, is not satisfied by the interpretation of v by f, then it does not matter whether Sj is 
satisfied under f, since the overall specification is satisfied regardless. This is exactly the 
result of qualifying the appropriate procedure activation in S] with predicate Q,on v. The 
constraint represented by Sj must be satisfied only if the qualifying predicate itself is 



-107- 

satisfied. Therefore, the transformation reiuktng fmm step M is consistent with preserving 
the meaning of the specifieation. and the valweretu*nc<i by the Sat predicate is the same 
when applied to the transformed specification s' as to the original * ^ ^ 

The next steps of the algorithm consttua the possible ordering* of the events for 
which the specification contains expression*, These ordering* represent sub-sequences 
within general bistoriesu The history in which eafih ordering is embedded is assumed t©*b e 
otherwise valid, with respect to the speaficatioru.. For this reason, an invalid ordenngs 
*■*•«,« ^ • ••* ."*»«tory that is not vaiidrwb^;a1#aM!arcbmngdma«»tgtnftfthe validity of tfre 
overall history. Therefore, a ce«ditic» lhat difl^ 
orderings is required to distinguish all valid histories from invalid ones. 

Step <4> of the derivation algorithm consist* of the construction of the set Evexp(s') of 
event expressions in the specification. This can he accomplished by using the formal 
definition of this set in Chapter 2. Thecal** *i#Mf*4 M J^ ^s^o^ #pecif^attoi* are 
exactly the gates associated with this set of e^t expression*. If #ier«pecificaMon re£e» to a 
certain set of qualified eveat classes, the solutiotv specif tcatKWV roust, comaui exactly this set of 
gates, since it is these classes of events that the ? guardian mm keep 5 track* of in order to 
implement the specified constraint. 

In step (5) all possible orderings among the elements of EvfxjjU'V are constructed. 
Each ordering actually represents a sub-sequenej of a hi*^|iConUuningrexactfy those 
events that are represented by the event expfe^ionA^is' under some interpretation. rSince 
there is no restriction at all on the quantificattoo, the range of the interpretation is the 
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comptete set of alt interpretations; This mean* that the ordering* together constitute the 
entire class of possible sub-historwj that ccmsiit of the eventt repreiented in the speafKation 
under any interpretation. • :;"■;••:. t -iqi b^rof^^v .-.. : -,- 

An ordering is considered possible unlm (a) there is some procedure activation whose 
enter event precedes, its request event, or whose exit event precedes its enter event? or («) 
there are two request events fo* the same procedure such4hat the invocation number of the 
earlier one is greater than the invocation nuiobw of the later one under all interpretations. 
This step corresponds to the restriction of ah* Tdomain of ;Valid to histories satisfying 
predicate Possible, which embodies these same restrictions. 

In Step (6), each ordering is used to evaluate specification s\ resulting in a 
classification of each ordering as either valid or invalid. Sine* the implicit interpretation by 
which the event expressions correspond to actual events -H unrestricted, an ordering is valid 
only if, under any interpretation whatsoever, each event m it satisfies the specification. An 
invalid Ordering, on the other tond, represent a sub-history which under some 
interpretation does not satisfy the specification. This is equivalent to the definition of the 
Valid predicate,' where for a history to be valid, each event in it must satisfy the 
specification for all interpretations. 

The identification of the offending event for each invalid ordering in step (7) is 
straightforward. The validity of a history with respect to a specif ication is defined in terms 
of each successive event in the history satisfying the specification. Since the history in 
which the ordering is embedded is valid otherwise, the first event at which an invalid 
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ordering fails to match some valid ordering is the "offending" one. All events preceding 
this one must satisfy the specification according to the predicate Sat. The definition of the 
validity of a history with respect to a solution specification similarly is in terms of each 
event satisfying the solution specification conditions. This means that the offending event 
must be the point at which SatSS is first not satisfied, and therefore a condition must exist 
that is violated here. 

Step (8) requires the state to be characterized at each point representing either a valid 
or offending occurrence of an event of the given (qualified) event class. As described in 
Section 4.2, this characterization is made by existentially quantifying all variables and 
putting bounds on the counts of all gates involved in an ordering. The existential 
quantification of variables signifies the fact that the event expressions correspond to actual 
events under some unknown interpretation, and that every variable is therefore replaced by 
some unknown value. Each bound on the count of passages through a gate is either a 
lower or upper bound depending upon whether the event at that gate precedes or follows 
the point at which the characterization is made. If event x m ,n,er precedes this point, then 
count(x en,er ) is presumed to be at least m, while if x m " n, ' r follows this point, then 
count(x onter ) is presumed to be less than m. For an event involving a qualified activation, it 
is the count of the appropriately qualified event class that is bounded. 

This characterization is accurate because the scheduling at each gate is 
first-come-first-served. According to the solution specification structure, two activations 

• 

whose parameters satisfy the same set of qualifying predicates must pass through exactly the 
same set of gates. Since the queue for each event class is FIFO, these activations must 
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proceed in first-come-first-served order. The rest of the state characterization method 
simply involves introducing the existential quantification on invocation number values 
explicitly, and including any explicit constraints on these values that may appear as clauses 
ins'. 

The characterization that is formed for each ordering represents the most general 
expression possible of the current state following the occurrence of a sub-history 
corresponding to the giveii^stderftig. htothing is. «sumed about the rest of the history 
except what can be deduced directly from the events Jn the ordering itself. All unknown 
values in the formula are existei**ia% <juanttfied>fiio the fermuta simply states that there 
exist some values for which its body is true. That is to say, there exists Mm* Interpretation 
causing a sub-history to correspond to this ordering. Therefore, D v , the disjunction of the 
characterizations from all the valid ordering!, represents the most general expression of 
when an event in the given qualified ckss can vabdly occur. Using the format semantic 
definitions of Sections 2.6 and 3,4, it is the most general characterization of CurSKh) for 
histories h which, when followed by some event e in the given class, satisfies the 
specification s* (by the definition of Sat) for any interpretation f. Similarly, D^ the 
disjunction of the characterizations from aD the invalid ordering*, represents the most 
general expression of when such an event cannot validly occur. This means that it is the 
most general characterization of CurSt(h) for histories that under some interpretation do not 
satisfy the specification when followed by an event in the class. 
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The preliminary condition formed by (D v A --(Dj)) in step (9) represents an attempt to 
incorporate all histories with which an event of the given class satisfies the specification for 
all interpretations, and to rule out all those with which it does not. It is the conjunction of 
two terms, one of which is the negation of Dj, the expression of when the event cannot 
occur. For this reason, it is guaranteed to be a strong enough condition to exclude all 
invalid oiderings, and therefore all histories that do not satisfy the Sat predicate for the 
specification. Therefore, no history that does not satisfy Sat will satisfy SatSS for the 
solution specification containing this condition for the given gate. Testing the condition 
against all valid oiderings determines whether or not it is weak enough to allow all histories 
satisfying Sat. If so, then it is the correct condition, in that it causes exactly the correct set 
of histories to satisfy the SatSS predicate as well. If not, then there are some histories that 
satisfy Sat but would not satisfy SatSS if ss contains the given condition. 

Progressively weakening the condition allows more histories to satisfy SatSS. This 
weakening is accomplished by repeating steps (10) through (13) using previous states, each 
time disjoining the resulting terms to the previous condition if they allow more valid 
oiderings to satisfy the condition. The weakening term constructed from the first 
application of steps (11) and (12) involves only quantities in the previous state. If this is 
found in step (13) to be not sufficient, then repeating steps (11) and (12) allows a term to be 

* 

constructed that involves relations between quantities in the previous state and those in the 
current state. Since each weakening term is of the form (D y ' A --(Dj')), just as the 
preliminary condition is, no invalid orderings can become allowed as a result of this process. 
By choosing each time an event that precedes the given point in all remaining valid 
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orderings still not allowed by the condition, the weakening terrni constructed have a good 
chance of including most rf not a If of the remaining valid orderings. Thefefbre, steps (10) 
through #3) in practice rarely need to be repeated more than ems^br twice E-ventually, iff 
vaJtd orderings must be wchided, unless the algorithm fails due to arr inability to find a 
previous state in step <10> to use in constructing new weakening terms. Specifications for 
which this the a Igorithm fa its are the subject of thelftst section of this chapter. 

4.7 Failure of the derivation algorithm 

The structure of the solution specification i« flexible enough to express the solutions to 
a large class of synchronisation problems However; certaih features do ftmit somewhat the 
range of synchronisation constraints' that can be expressed The solution specificatbri 
structure is less general than the problem specifieattori 1afl$«age* ^Ihat^ for some 
specifications the derivation algorithm is unable to construct equivalent solution 
specifications. As noted in Section 4.2, this sometimes is manifested by finding the 
offending event in an ordering to be other than an enter event Since this would imply a 
condition on a request or exit gate, such a specification is incompatible with the solution 
specification structure that only places conditions on enter gates. The algorithm therefore 
fails whenever an invalid ordering is found for which the offending event is not an enter 
event. 
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Tbe other manifestation pf incompatibility with the ^ructure of the sohition 
specification is an inability to find sufficient previous states at which terms can be 
constructed to weaken conditions. An example of such an incompatible specification is the 
"last-come-first-served" (LGF5> scheduling specification of Example 6 in Section 2.7: 

( p ,requ«St ^ p request =} p.tnl.r) ^ (p« n ««' =* $£**"). 

When the derivation algorithm is applied to. titu> spedficaMoOr the following preliminary 
condition i is first constructed for gate p en,,r : 

wuiU(p r ^ 8 V J om, ft t(p Mtaf ) *l 
This condition js found not to be sajtsjfied; by em jofc the 5 events occurring in a valid 
ordering, however, namely Pi ,n, * r in the vaUdorder^ 

p^uest ^ ^ rtqwst ^ p «nl«r -^ p^ntw 

This must be distinguished fronuhe offending event pj # "!* f in tt»ejnvalid ordering 

on the basis of previous state information. Since these orderings differ only in the identity 
of which of the two p en,er events occurs first, and the identity is not reflected in any 
predicate on the parameters of the two activations, it is obvious that the two cannot be 
distinguished. In applying the algorithm, there are two previous events at which possible 
weakening terms can be constructed: the most recent, and next-to-most recent, p r • < ' • s, events. 
However, the state characterizations for the two orderings are identical in each case, 
resulting in potential weakening terms that are identically FALSE and thus not useful. As a 
result, the derivation ends in failure, since no other possible weakening terms are available. 
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. The reason for the failur* of the algorithm e* this specification is that the property 
specified requires two different activations to be distinguished, not on the basis of their 
parameters, but simply fcy their identity A soKrtioo specifK^tron condition for this 
constraint would have to depend on not only the number of previous events, which would 
involve the current synchronization state; or even the Vrfer oif these events, since this 
ihformatidn can always be obtained from prevkw j state mformStion, as exphHned in Section 
3.3. Instead, the constraint relies on distinguishing theli*l«n^ of t#o ^hWereilt activations 
However, since there is no parameteWelit^ prope% 'b? which to distinguish the two 
activations, the structure of the solution specification requires 1 that the activations pass 
through the same gate or set of gates for the p"^ event dais in FIFO order. The 
requirement in the specification of non-FIFO scheduling is in direct contradiction with the 
solution specification structure. This is why the derivation algorithm cannot possibly 
succeed in deriving a solution specification for this specification. 

Synchronization constraints such as the LCFS specification that rely on the identity of 

particular events are rather unusual in practice, and their incompatibility with the solution 

specification structure is not terribly distressing. A second kind of incompatibility, though, 

is demonstrated by a very commonly desired property, the first-come-first-served (FCFS) 

specification of Example 5 in Section 2.7: 

( p .r«q«*St _^ q. '«>«•»') w (p.« lrt « f =* q i ,lrt * r ). 

This specification, somewhat surprisingly, is also one for which the derivation of a solution 
specification fails. The reason is that this synchronization constraint cannot be implemented 
using one queue for each event class and one entry condition for each queue. An 
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implementation using the serializer construct appears in [Hew773 for a FCFS scheduling 
property on two operations "read" and "write", but this relies on the two operations sharing 
the same queue* though with different entry conditions. A mbrrttor implementation was 
devised in an unpublished note [Bro76], but here again the two operations shared a single 
queue, with one of the operations using a second auxiliary queue as well. 

The reason that a solution specification cannot be constructed for this property is that 
it would be necessary to save information at a previous state that is arbitrarily far back in 
the history. The solution specification structure allows states to be saved at the most recent 
event at a gate, and by extension, at the neKHo*most recent, etc Howfcver, the FCFS 
constraint requires that each enter event' use information from the point m the history at 
which the corresponding request event took place, which may be arbitrarily tar back. That 
is, the condition fof eirtep events by different processes must involve information saved at 
previous states individually applicable to each process, Specifically, let 

[count<ec) private • pff ( w ,rtt 3 
be a quantity that for any particular activation of operation p represents the value of 
count(ec) saved at its request event. Then the conditions on gates p - ^ and q* n ^ r could be 
expressed as: ..■-"-;', 

p ent ^ [coH«t<q ,,q ^> private • ^• < *^3* ee««(q•? , • , ) 

q en,er : [countfp''^ 8 ') private • q r ^ $t ] - count(p" n, ' r ) 
That is, there must be as many q ,nt,r events at the time of a p ,nUr event as there were 
qrequast events wnen the given activation of p was requested. 
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The use of this kind of information that is 'private' to each process appears in 
[Qwi76] to specify solutions to synchronization problems. Interestingly, *be LCF$ property 
can also be expressed with the use of private information. The condition on, gate p*" , * r 
becomes: 

(coun^p'*^") - [co^ll^t(p , • , » wW, } private « p**"*^ « 
(count(p' n,,f ) - [count(p* n,,r ) private • p r *^» t ]) 
In other words, all requests for p since this activation of p was requested must first be 
fulfilled. 

The solution specification can only save state* at* "fixed" distance back from the 
current state, where "fixed" is relative to the number of events at a gate. Information 
privately saved by each process must be saved at states arbitrarily far back in the history. 
Without such privately saved information, the sohition specification structure is unable to 
express certain properties/including the rather straightforward FCFS property. This must 
be considered a weakness of the solution specif ication and therefore of the synthesis method. 
However, it is nevertheless true that most specifications are compatible with the solution 
specification structure, so that the derivation algorithm dec* succeed in constructing 
equivalent solution specifications in most cases. The next chapter describes the last step in 
the synthesis for these cases, the ampleroerttttioo of the sokition specif ication in actual code. 
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Chapter 5 
The Source Language Implementation 

5.1 Introduction 

The derivation of an equivalent solution specification from a problem specification, 
using the algorithm presented in Chapter 4, constitutes the major conceptual task involved 
in synthesizing actual synchronization code. The derived solution specification is a 
procedural representation of the same ordering constraint that is expressed non-procedurally 
by the problem specification. The final step in the synthesis is implementing the solution 
specification in terms of an appropriate source language synchronization mechanism. The 
translation from solution specification to source language is the subject of this chapter, and 
while relatively straightforward, it is not completely obvious for all cases. 

The structure of the solution specification is general enough for it to be translated into 
any one of a wide range of source language synchronization mechanisms. For purposes of 
explaining and illustrating the translation technique, the monitor construct of Hoare 
([Hoa 743) will be u$ecl [throughout the thesis. An implementation using an alternative 
high-level synchronization mechanism such as conditional critical regions (LBri72)> or 
serializes ([Hew77]) would be quite similar. If a lower-level mrchanism such as semaphores 
([DijOS]) is preferable, then an algorithm giveo in [Hoa74] can be used to further translate 
the monitor implementation given here into semaphore code. 
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A fundamental assumption of the mode) used here is that all synchronization for a 
data object takes place through a single centralized rnecbanism associated with that object. 
This does not cause any problems with an implementation in terms of monitors, or any of 
the other constructs cited above. However, it does make the solution specification structure 
somewhat incompatible with situations in which a data object is distributed throughout 
some decentralized system, and where it is desirable for the synchronization control similarly 
to be distributed. The structure of the solution specification does not give much aid in 
deciding how to perform the message passing required in a distributed system to implement 
the synchronization constraint. For centralized synchronization mechanisms such as 
monitors, though, the implementation is not too difficult, as wiH be demonstrated once the 
monitor construct itself has been introduced in the next section. 
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5.2 Monitors 

The monitor is a synchronization mechanism that was first described by Brinch 
Hansen in [Bri73] and defined more formally by Hoar* in IHoa74l ft grew out of the 
"secretary" concept proposed by Dijkstra in {Dij72bl A monitor is an extension of the class 
construct of Simula [Dah72l with one important difference. A monitor, like a Simula class, 
consists of some local data and a collection of procedures for manipulating that data. The 
major difference is that executions of the procedures of a monitor are mutually exclusive, In 
order to protect the integrity of the local data. Processes attempting concurrent executions 
of a monitor's procedures must wait to gain exclusive access to the monitor. This waiting is 
defined by Hoare to be fair, and can be assumed to follow a first-come-first-served 
discipline. 
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Monitors also contain features for explicit process synchronization. As defined by 
Hoare, this takes the form of a condition data type, which represents a FIFO queue of 
waiting processes. Two operations are defined on a condition for queuing and dequeuing 
processes: "wait", which causes the process executing the operation to enter the queue; and 
"signal", which dequeues the process at the head of the queue, if any. Both operations cause 
the process executing the operation to relinquish possession of the monitor. A process on a 
queue that is dequeued via a "signal" operation by some other process regains possession of 
the monitor. It resumes execution of the monitor procedure it was executing at the point 
immediately following the "wait" operation that it performed. An additional operation 
"queue" returns a boolean value, indicating whether any processes are on the queue. 

The notation used here will be based on the language CLU [Lis76] rather than the 
Simula -based notation introduced by Hoare. Thus, a "wait" operation on condition variable 
c is written 

condition$v/dLit(c); 
rather than 

c.wait; 
as in [Hoa74j. 

Hoare advocates associating informally with each condition variable a boolean 
predicate on the local data of the monitor. This predicate indicates what condition on the 
monitor state a process on the queue is awaiting. Making this association aids in proving 
properties of monitors. As indicated in the next section, this association makes condition 
variables suitable for representing the entry conditions in the solution specification being 
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implemented. 

5.3 The basio monitor implementation 

A comparison of monitors with the sofetfon specification structure discussed in 
Chaptei 3 reveals a close correspondence between features of one and the otner. The focal 
data of a monitor is sufficient for representing the state information required In a solution 
specification, since this state information can be represented by a. collection of integer- valued 
quantities. A condition variable in a monitor is a FIFO queue of uniting processes, and as 
advocated by Hoare, has associated with ifcta&rnwttya boolean predicate on the monitor 
data. These are exactly the features required for conditions associated with enter gates in a 
solution specification. Passage through a set of gates associated with a given event class 
must be indivisible and produce a state change in the system. Monitor procedures are ideal 
for implementing gates, in that they manipulate the local data of the monitor, and because 
the enforced mutual exclusion on their executions makes them indivisible operations. 
Monitor procedures can take parameters, which is important since the behavior of gates 
sometimes depends on the arguments to the associated procedure activation. 

It should be emphasized here that the monitor is being used to implement only the 
synchronization code, not the abstract data type as a whole. The monitor was originally 
conceived in [Hoa74] to implement a shared data abstraction itself. Criticism of the monitor 
construct has appeared in some recent technical literature (e.g. [Hew77l [Had773, tjam77]>. 
The basis of this criticism has been that the use of monitors to implement abstract data 
types leads to such problems as reduced concurrency, lack of modularity, and a potential for 
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deadlock through hierarchical monitor calling. As used here, however, the monitor is 
employed within a data abstraction, for the sole purpose of implementing the 
synchronization code required by the operations of the abstraction. The monitor procedures 
are kept small in size, so that their use does not significantly affect the degree of 
concurrency possible. Modularity is enhanced by implementing the synchronization code 
separately from the abstract data operations. Since lower-level abstractions are called from 
the bodies of the operations, not from the synchronization code, the problem of hierarchical 
use of monitors is avoided. (See [Blo78] for the advocacy of a similar discipline in the use 
of monitors.) 

The monitor for a data type contains three procedures for each operation p of the 
type. These procedures represent the three event classes associated with p, and are named 
p_request, p_enter, and p_exit. It is necessary that the procedures of the derived monitor be 
called at the proper points within the data abstraction operations, in order to ensure that 
the monitor is used properly and the synchronization constraint is embodied in the data 
abstraction. The form that operation p must take is illustrated below in Figure 5.1. The 
identifier "m" is the name of the constructed monitor, and v is the vector of parameters to 
operation p. This vector of parameters actually must be passed to the monitor procedures 
only for implementations involving qualified gates, as explained in Section 5.5. 

The monitor implementation of a "basic" solution specification that involves neither 
previous state information nor qualified gates is straightforward. Recall that the abstract 
program for an activation of operation p of the data abstraction in such cases is given by: 



122- 



Figure 5.1. Monitor calls within operation p 

pmprx... ; 

call m.p_request(v); 
call mpjenteft*)} 

. <bodyofp) 

call m.p_exit<*fc 
«nrf p; 



p'"***': increment cpafl^p'**^ by I 
p" >,w : wait until entrjf ^^cqiwii^pn^ ^sfte^ 

then increment co^^Bt(p• ,,to, ) by 1 
execute body of operation p 
p""': increment coun^p - ***) by 1 

. For each quantity of the form count(ec) that appears in one or more entry conditions 
in the solution specification, there is a corresponding variable of type integer in the monitor. 
This variable is initialized to 0, and is incremented by 1 in the procedure that represents 
event class ec. 

An alternative implementation could employ instead a separate variable for each 
quantity of the form (couiitCecj) - countfec^X since a condition almost always concerns the 
difference between, two tountt,. The imptementation cho^tn J*e«fi i* somewhat simpler fqc 
purposes of explanation. It does, however, incur the possibility of integer overflow, since 
each variable is constantly increasing over time. Although techniques can be used to avoid 
overflow by dynamically extending the precision of integers, the alternative might be 
preferable in practice. 
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For each enter gate with an entry condition in the solution specification, the monitor 
contains a condition variable. The boolean fired tcate informally associated with this 
variable inexactly the same.as the entry coflditj^with .each j^anti|y of the form c;ount(ec) 
replaced by the corresponding variable. Let the condition variable corresponding to gate 
p ent«r be pentr y an0 - denote the predicate associated with it as C„. Then the first statement 
in procedure p_enter is 

if (-> C ) then conrfirionSwait(pentry); end; 

r 

Whenever control of the monitor is relinquished, it is necessary to check the predicates 

associated with all condition variables on which processes are queued. If one or more of 

these predicates are satisfied, then a "signal" operation is 5 performed on one of the 

conditions. The condition to be signalled must be chosen in a fair manner, so that no 

process starves because the condition on which it is queued is never chosen for signalling. 

This can be accomplished by using a variation of Dijk&raY %ulrdect commands" [Dij753 to 

implement a new kind of statement called a "choice" statement. Changing Dijkstra's 

notation so as to distinguish choice statements from ordinary if statements, a choice 

statement looks like: 

choose 

B,: Sj; 
B 2 : s 2 ; 



B n :s n ; 
end; 
where the number of guarded commands n > 1. The meaning of this statement is the 

following: The "guards* Bj are simply boolean expressions. If one or more of these guards 
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are true, then one of the true guards B» is (rkjtt-determinsuely) selected and the 
corresponding statement Sj is executed: There are two 1 important differences between tfrts 
statement and DijkstraV version. The method for making the selection between several true 
guards is unspecified but must be fair. Also, if hone of the guards is true, then the 
statement is simply skipped. 

If the condition variables in the monitor are pentry, qentry, etc with corresponding 

boolean predicates C_, C_, etc., then the following choice statement must appear at the end 

of every monitor procedure: 

choose 

«mrfirto;i$queue(pentry) a C p : conrfiriontsignaKpentry); 
con<titt<mSqueue(qentry) A C- condtftontsignaKqentry); 

end; 
This ensures that whenever one or more waiting processes can be dequeued, due to the 

satisfaction of the predicates on which they are waiting, one of them, will in fact be 

dequeued. The fact that the predicates in the guards include the, conjunct of the form 

conrf/7i'owtqueue(pentry) ensures that the condition that is signalled does in fact have a 

waiting process. As long as the selection is made fairly, the monitor will be a faithful 

implementation of the solution specification. 

A property of the monitor construct that is used here is that a process that is dequeued 
from a condition variable via a "signal" operation gains possession of the monitor ahead of 
any process that is attempting to call, a monitor procedure This ensures that a process that 
has been waiting for an entry condition to become satisfied is. allowed to proceed as soon as 
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the condition is in fact satisfied, and is not overtaken by a later-arriving process. This 
property is necessary for the faithful implementation of the FIFO scheduling that is part of 
the solution specification structure. 

In practice, it is often possible to optimize the signalling statement by eliminating some 
of the options in the choice statement. The basis for such eliminations is that the 
corresponding guards cannot possibly be satisfied at the given point in the monitor, due to 
the rest of the monitor code. In fact, for many simple examples, at most one guard in the 
choose statement can ever be true at any given point. However, in general the analysis 
required to perform this optimization is difficult. Rather than becoming involved in the 
details of when a given option can or cannot be eliminated, the simple-minded 
implementation of always testing all conditions will be used here. (In practice, it might be 
simpler to make a separate procedure internal to the monitor for this signalling code. Each 
of the regular monitor procedures could then call on this internal procedure.) 

An optimization that can be made easily is the elimination of unnecessary monitor 
procedures. If no reference is ever made to the quantity count(p reqo * sl ) or coun^p" 1 "'), then 
the body of the corresponding procedure is empty. The procedure itself, along with the call 
to it within the data abstraction operation p, then can be eliminated. Similarly, if there is 
no entry condition associated with gate p enUr , and no reference to the quantity count(p* n '* r ), 
then procedure p_enter can be eliminated. 
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As a concrete example of a monitor, implementation, consider the following 
specification: 

((p/*^" => qf*») d (p^ =*qf*? )) a 
«qj ,n,w => Pi"""') D ^j*** =* pj""*)). 
There are two clauses, one giving operation p priority over operation q, the other excluding 
new activations of operation p during active executions of operation q. The solution 
specification for this example consists of the conditions 
For gate q' n ^ cwin^p'"^ 1 ) - oo«nt(p" l,w ) 
For gate p""": countfq"**) - count(q" ,i, ) 

The monitor implementation of this solution specification contains four integer 
variables, representing cQunt(p , • < ^• s, ), ©ouat^p"*"), oMmt^) *nd coMPtftq* 1 "'}. These 
variables are named pr.pn, qn, and qx, respectively. Zach variable must be initialued to 0, 
and incremented by I in the corresponding n^itorp^oceduje. There are two condition 
variables, pentry and qentry, for the entry conditions on gates p"" #r and qf tar . The 
predicates associated with these condition variables are the analogues in terms of monitor 
variables to the solution specification entry conditions: (pr - pn) for qentry, and (qn - qx) 
for pentry. The monitor "ex" that is obtained for this example appears in Figure 5.2. The 
monitor procedures p_exit and q_request have been eliminated as unnecessary. Operation p 
of the data abstraction must call monitor procedures ex.p_request and ex.p_enter (in that 
order) before executing its body, while operation q must call procedure ex.q_enter before 
executing its body, and ex.qjexit afterwards. 
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Figurc 5.2. Monitor for example 

ex * monitor; 

pr, pn, qn, qx: integer; 
pentry, qentry: condition; 

p_request • procedure; 
pr i= pr ♦ 1; 
choose 

condition%queoe{pentry) A qn - qx: coruftttontsignaKpentry); 
condUiontywelfpntry) a pr - pn: cond«ia^|signaKqentry); 
end; 
end p_request; 

pjsnter * procedure; 

if qn * qx then a>r»rfrtt07iiwait(pentry); end; 

pn :- pn 1 1* 5 

choose 

conrf^ionlqueue(pentry) a qn - qx; conditumtugmKpentry); 
condition$queue(qentry) a pr - pn: contfttttmtsignaKqentry); 
end; 
end p_enter; 

q_errter - procedure; 

if pr * pn then conrft«ontwait(qentry); end; 

qn :« qn ♦ 1; 

choose 

, conrfi(wn$quet|e(pentry) a qa » qx: c^tyipnt^m&peQtryY. 
conrfifionSqueue(qentry) A pr - pn: condtfwntsignaKqentry); 
end; 
end q_enter; 

q_exit - procedure; 
qx := qx + I; 
choose 

conrfiriontqueue(pentry) a qn - qx: condiUon$signa\(pentry); 
con<tirionfqueue(qentry) A pr - pn: condi«onl$ignal(qentry); 
end; 
end q_exitj 

pr, pn, qn, qx :- 0, 0, 0, 0; 
end ex; 



5.4 Previous state information 

When a solution specification contains references to quantities riot only in the Current 
state but also in previous states, these quantities must be nuintalnetl In the monitor in a 
different manner. Specifically, a separate monitor variable, is required for each quantity of 
the form "[count(ec) •'■gf; inhere g is some gate. ^U s %atiaotiof 'tyjpe tnte^tr saves the 
current value of the variable representing count(ec) in the monitor procedure corresponding 
to gate g. That is, it is set in the procedure representing gate *|^©y assignii% to it the 
current value of the variable representing count<ec). It can be used in the boolean 
predicates associated with ccwdmon variables in the sime way as a variable that represents 
a quantity in the current state. 

Consider example 7 from Chapter 2, the specification for "operation pairing": 
<a i " tor =» b{*~) ♦♦ (c i ""*" r ==> dj*" Ur ). 
The derivation Of the soluUori specification for this e*ampfc was started in Section 4.2. The 
overall solution specification is: 

For gate a ,n,,r : 

(count(b' n,,r ) > count(d' B,,r )) v ([count<a , " tor ) • d"*"! < tcowit(c w,w r • d"*"]) 
For gate b*"*": ' i: --—■'- /;:;:^.t^^-:.- - 

(count(a #n,,r ) > count(c* n,w )) v (Ccotwt<b , " tof ) • c*^ < {countM**^* • <**T) 
For gate c" n, ' r : - f 

<count<d ,n, ' r ) > count(b wrt#r )) v acoun^c - "**) • h"**} < lanntb"*") • b wtar 3) 
. For gate d*^^: 
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(count(c en,er ) > count(a en,er » v ([count(d en,,r ) e a en,ef ]) < tcount(b ,n " r ) @ a en,,r ]) 

Since the entry conditions do not involve any request or exit gates, only four procedures are 
needed in the monitor, one for each enter event class. Each of the operations a, b, c, and d 
must call the appropriate monitor procedure prior to executing its body. The variables an, 
bn. en, and dn can be used to represent the current counts of the four enter event classes. 
In addition, eight other variables are needed to save the values of counts in previous states. 
Variable amrd, for example, represents the count of gate a* nUr saved at the most recent 
d en er event. This variable is set in monitor procedure d_enter to the value of an, which 
represents the current value of count(a enUr ). Similarly, variable cmrd represents the count 
of gate c en,er saved at the most recent d en,er event. The predicate for the condition variable 
aentry on which procedure a_enter performs a wait operation is: 

bn > dn v amrd < cmrd. 
The predicates for the other condition variables bentry, centry, and dentry are analogous. 
The complete monitor appears in Figure 5.3. 

5.5 Qualified gates 

The remaining issue to be handled is the implementation of qualified gates, which 
arise in a solution specification from the presence in the problem specification of predicates 
on the arguments to procedure activations. Recall from Chapter 3 the abstract program for 
an activation of operation p in a situation involving qualified gates: 
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Figure 5.3, MoHitor for operation pairing ^x»i«|»lc (XV - j:j 

pairs = monitor, 

$r) t bn,w*<teiM?g*?i ^ . .. ■, ■-:.,- .-::.- . . ---- : -j^ -:-?^ 

amrd, cmrd, bmrc, dmrc? integer; 

amr^, crnr>, hoira A di«rJi;Jj|^rr; ....„._ 

aentry, bentry, centry, dentry: condition; 

a_enter « procedure; 
,..,..-,., ,$|f (bn < dn,A airard > anrd)l4f* <an4#foniwait(aentry); #nd; 
an := an + 1; 

_._ . . bmra :«= bn; -,.=-•«. ; ■■•;,.: - 

dmra := dn; 

C/lOOSe . ,. , .-'is, ..,, .^ -, ( _.. : _,,..„, .., ,;...-..■.. ,.-,. ;■-., , ■ ;.' -. . ' 

condition$queue(aentry) A (bn >dnv amrd < cmrd>. conrfttiontsignaKaentry); 

; con<iUiw$qytw$^tfyl/s 4»a.&<cn ybjpr%f: ll?^)^l?i<^'tll^^W*i««ry)*' 
conrfirionlqueueCcentry) a (dn ikv cmrb < amrb): eendtttonisignaKcentry); 
cond.Won$$w*i0!A*vtry) A (en > an w dwa < brura>. w«f«tonlfignaJ(dewry); 

*nrf; 
enrf a _enter; » , ^' 

b_enter = procedure; 

</(an < en a bmrc > dmrc) rA«i con<ffttontwait(bentry); «nd; 

bn :- bn ♦ 1; 

amrb :- an; 

cmrb :- en; 

choose 

conrfiriontqueue(aentry) a (bn £ dn y amrd < cmrd>. condi#<m$sigr»aJKa.emry); 
conrfittontqueuetbentry) A (an > en v bmrc < dmrc): conrfiirtontsignaKbcntry); 
«mrfifiontqueue(centry) a (dn > bn v cmrb < amrb): amrftttonisignaKcentry); 
contftr/ontqueuetdentry) a (en > an v dmra < bm^< ^^f j)ao ^ ^a^dgntry)-. 
end; 
end b_enter; 

c_enter = procedure; 

if (dn < bn a cmrb fc amrb) then con<tition$wa\t(&enlry); end; 
en :«■ en ♦ I; 
bmrc > bn; 
dmrc :■= dn; 

conrfto'onSqueuHfaentry) A (bn > dn v amrd < cmrd): condirfcmf signaKaentry); 
conrfiriontqueue(bentry) a (an i en v bmrc < dmrc): ceitdtttonisignaKbentry); 
con rfiriontqueue(cen try) a (dn £ bn v cmrb < amrb): «mrf«kmtsigna1(centry); 
am<frfton8queue(dentry) a (en > an v dmra < bmra): condWontsignaKdentry); 

end; 
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end c_enter; 

d_enter = procedure; 

if (en < an a dmra > bmra) then condition^ wait(den try); end; 

dn := dn + 1; 

amrd := an; 

cmrd := en; 

choose 

conrf/rionjqueuefaentry) A (bn > dn v amrd < cmrd): conrfifion$signa1(aentry); 
condition$queue{ba\try) a (an > en v bmrc < dmrc): conrfirtowtsignal(bentry); 
condition$queue(centry) a (dn > bn v cmrb < amrb): con<toton8signal(centry); 
condition$queue(deniry) a (en > an v dmra < bmra): contfrtfontsignaKdentry); 
end; 
end d_enter; 

an, bn, en, dn := 0, 0, 0, 0; 
amrd, cmrd, bmrc, dmrc := 0, 0, 0, 0; 
amrb, cmrb, bmra, dmra := 0, 0, 0, O, 
end pairs; 
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^request. in para || e | f or a |j gatcs g in event c | ass pfequrt^ 

if v satisfies the qualifying predicate of g, 
then increment count(g) by I 
p en,er : in parallel for all gates g in event class p eMer , 
if v satisfies the qualifying predicate of g, 

then wait until the entry condition of g is satisfied, 
and then increment count(g) by 1 
execute body of operation p 
p'* A : in parallel for all gates g in event class p exi \ 
if v satisfies the qualifying predicate of g, 
then increment count(p•'" , ) by 1 

How this abstract program is implemented in a monitor depends to some extent upon the 
nature of the qualifying predicates. In all cases, though, it is necessary that each of the 
monitor procedures p_request, p_enter, and p_exit take the same vector of arguments as the 
data abstraction operation p itself does. This allows the monitor, procedures to test the 
qualifying predicates on the arguments, thereby determining which gates apply to an 
operation activation. Each monitor procedure implements the entire set of gates for the 
given event class. 

Qualified request and exit gates are easier to implement than qualified enter gates. 
Since these gates consist only of incrementing integer variables, it is merely necessary to test 
the qualifying predicate before incrementing. The simplest case involves a predicate 
concerning only the arguments to the associated data type operation. A qualified count, like 
an unqualified one, is represented by an integer variable initialized to 0. The update to this 
variable is preceded by a test of the qualifying condition, and is only made if the condition 
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is true. For example, let the qualifying predicate be Q(v), i.e. the quantity to be updated is 
something like count([p(v) | Q^v)] B ' lrt ). If x is the monitor variable representing this 
qualified count, then the update statement in procedure p_exit is 
i/Q^v) then x:=x+l; end; 

There may be more than one qualified gate for an event class, in which case a 

separate state variable is required for each gate. The update of each state variable Xj must 

be preceded by a test of its corresponding condition Q^ Because more than one of these 

conditions may be simultaneously satisfied, it is important that the tests be made in a series 

of statements of the form 

if Qj(v) then Xj := Xj ♦ 1 end; 

rather than in one statement such as 

i/Qj(v) then Xj := Xj ♦ 1 
elseif Qg(v) then X2 :- X2 ♦ 1 
elseif ... end; 
that could only increment one variable at most 

A qualifying predicate may be parameterized, and so involve not only the arguments 
to the associated operation, but also a parameterizing variable t. (There actually may be 
several parameterizing variables t- v but they can be combined into one composite variable t 
= <tj, ..., t n >.) For each possible value of t there is conceptually a separate gate, which means 
there must be a separate quantity in the state. For example, suppose that a solution 
specification contains a quantity of the form count([p(v) | Q£v, t)]" xit ). If the parameterizing 
variable t were of type integer and could only take values from a restricted range, say 1 to 
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100, then this quantity could be implemented by an array with that subscript range. The 
n-th element in the array would represent the quantity eouBttfp(v) | Qjv,n)9 M ' t ). 

In general, of course, variable t is not necessarily an integer, and it is impossible to 
know ahead of time all possible values for t. The same idea can be used in the 
implementation, though, by employing an abstraction that captures this same effect. The 
parameterized type "counfctTr, where T represents the type of ti con tarns counts for alt 
possible values of i, at least conceptually. Ttu^con^ are alt set to ^Initially when ar new 
object of type iountstt"] is created, and ^te count corresponding to a particular value t(j is 
incremented by the operation "incr" with tQ as argument. 

In the actual implementation of the type countsTT], the count for any particular value 
of t is created and added to the object of type countsTT] only as it becomes needed. The 
implementation of this type in a language with dynamic arrays such as CLU is 
straightforward. However, the dynamic creation of counts as they are needed is an 
implementation detail; users of the type can ignore this arid iise this abstract conception of 
all counts that are needed being created as pan of the object initially. 

For the purpose of translating a solution specification into a monitor, each state 
variable representing a qualified count Whose predicate Is parameterized i>y variable t ! must 
be implemented by an object of type 1 cbuhtstTt A 'create* operation for this object is 
required in the initialization code of the monitor. The qualifying predicate must take the 
form of a functional relaticnri between variable T and the arguments of the procedure 
activation, i.e the qualified quantity must be of the HH-m count([p(v) J t - f(v)7 nX ). It is 
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always possible to parameterize a predicate so that at most one activation is non-functionally 
related to the parameterizing variable t. This activation should be chosen to be the one for 
whose enter event the condition is derived. This means that only one value of t can apply 
to any given activation, and so only one count needs to be incremented. Incrementing the 
proper count is accomplished by the statement 

counts[T]|incr(cou, f(v)) 
where T is the type of t and cou refers to the object of type counts[T]. 

There must also be an operation "get", analogous to the "fetch" operation on arrays, by 
which the count for any particular value of t can be retrieved. This operation is used 
within the predicates for conditions associated with parameterized enter gates, as explained 
below. The quantity 

count([p(v) | (t - f(v))]" H ) 
in a solution specification entry condition is implemented by the operation call 

countsTT]Sget(pexitcount5, f(v)), 
where the object referred to by variable pexitcounts represents count([p(v) | (t - f(v ))]•*'*). 

Qualified enter gates are more complicated to implement than other types of gates. 
Not only must a quantity of the form count([p(v) | Q(v))] MI<ar ) be updated, but first some 
entry condition must be satisfied, which means that waiting must be implemented. The 
simplest case is when there is a single qualified gate for the event class, and where the 
qualifying predicate is only on the parameters to operation p. Then there is a single 
condition variable "cond", just as for an unqualified enter gate. The wait operation on 
"cond" is preceded by a test of the qualifying predicate Qjv) as well as the associated 
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predicate C: 

if Q(v) a (-• C) then conrfifion$wait(cond); end; 

When an enter event class contains more than one gate, each with a different 
qualifying predicate and entry condition, then there must be a separate condition variable 
for each possible subset of gates whose qualifying predicates may be satisfied by an 
activation. The boolean predicate associated with each condition variable consists of the 
conjunction of the entry conditions on all gates in the subset of gates to which the condition 
variable corresponds. An unqualified gate, of course, applies to every activation, so if there 
is an unqualified gate, its condition must be part of every predicate. In cases where two 
qualifying predicates are contradictory, or where one implies another, some subsets of gates 
will be impossible and can be eliminated from consideration. 

For example, assume a solution specification contains the following entry conditions: 

For gate p en,,r : count(a en,er ) = count(b ,nUr ) 

For gate [p(v) | Qj(v)] en,,r : coullt(a re, ' u • 8, ) = count(a ,nUr ) 

For gate [p(v) | Q2(v)] enUr : counKb"" 1 ') - coullt(c• n, • , ) 
Assuming that predicates Ql and Q2 are not contradictory, and that neither one implies the 
other, then there must be four separate condition variables. These must cover the 
activations satisfying neither Ql nor Q2, both QJ and Q2, and either one but not the other. 
The unqualified gate applies to all four cases, of course. Let variables ar, an, bn, bx, and en 
represent the quantities couIlt(a r • < ' u •• , ), count(a ,nU '), count(b ,nUr ), count(b* x,, ) 1 and 
count^"'"), respectively. The predicates associated with the condition variables are then 

cO: an = bn 
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cl: an = bn a ar = an 

c2: an = bn A bx - en 

c3: an = bn A ar = an a bx = en 

The code involving these variables at the beginning of monitor procedure p_enter(v) is: 

if Q2(v) a Ql(v) a (an * bn v ar * an v bx * en) 
then C0n<fotontwait(c3); 
eheifQ2{v) a (-■ Ql(v)) a (an * bn v bx * en) 

then condition$waH(c2y, 
elseif ir Q2(v)) A Ql(v) a (an * bn v ar * an) 

then coTutiftonSwaiKd); 
elseif (an * bn) 

then condition%wait(cOy, end; 
It <^| and Q2 are contradictory, then condition c3 may be eliminated, while if one implies 

the other, then either cl or c2 is not needed. 

A qualifying predicate on an enter gate that involves a parameterizing variable t 
presents the most difficult implementation problem. Since this construct actually represents 
a separate gate for each possible value of t, a separate condition variable is needed for each 
possible value of variable t. To implement this, what is required is something like an array 
of conditions, but with a dynamic range, so that new conditions can be created and added to 
it. 

The implementation uses a type called "conditionsTT]". An object of this type contains 
an object of type condition for each value in its domain. The initial domain of the object 
returned by the "create" operation is empty. In general, the domain consists of the set of 
values of t that have been explicitly added by means of the "add" operation. The "add" 
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operation creates a new condition only if one does not yet exist for the given value of t, so 
that subsequent calls on "add" with the same value of t have no effect. The predicate 
associated with each condition is parameterized by the associated value of t, and so is of the 
form C (t>. Notice that while the exact set of conditions fs determined dynamically by the 
"add" operations, the form of* the predicate for each one is fixed, except for the Value of the 
parameterizing variable t. 

The first step in implementing parameterized ente^^^ the enter 

gates in the event class into all possible combinatioosjof. sa tt&fia bte qualifying predicates. If 
there is an unqualified gate for the event class, then its entry condition becomes a conjunct 
of the parameterized condition C_(0. When there are individual (non-parameterized) 
qualified gates, then the same analysis as to possible subsets of satisfied gates must be made 
as was discussed above and illustrated by the example involving predicates Qj and Q2. As 
before, there mast be a condition representing each possible subset of gates through which a 
given procedure a<rtivaticriml>y^ requires a 

separate object dr ! ryp* ; condtaotfstT] for eaih cbmbmatibn of gates including a 
pararneferized gate: ThS remairulig discussion" focuses oh a single object of type 
coritfittonstn but notes how to generahie to cases involving many such objects 

Given an enter gate qualified by some predicate parameterized by variable t, the 
relation J? between variable rand parameter Vector v of the operation being qualified may 
or may not be a ftmttion. ff it is *a f untitle/ tne^uMlifyihg predicate'takesthe form t - f(v). 
The condition on which tb possibly wait is th^louiia % cafflitg the "gei" operation on the 
object conds of type conditionslT] with argument ff>j: ThV^get* 'operation, similar to the 
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"get" operation on countstT], retrieves the condition corresponding to the value of its second 
argument. The code for waiting in the monitor "enter" procedure is therefore: 

if(- C p (f(v))) then con<tiri0nSwait(conditions[T]tget(conds, f(v)»; end; 
To guarantee that the object conds does in fact contain a condition for the associated value 
of t, the statement 

conditions[T]Sadd(conds, f(v)); 
is used to add the appropriate condition to the set of conditions in object conds if it is not 
already there. This operation must precede the waiting statement, a fact that can be 
ensured by placing it at the beginning of the "enter" procedure. 

An optimization that is possible is to only add the condition to conds if a "wait" is 
actually performed. That is, instead of locating the "add" operation at the beginning of the 
monitor procedure, instead it can be placed inside the then clause of the if statement 
immediately preceding the "wait".. In addition, after the process finishes waiting on the 
condition, i.e. after being signalled, the condition created may no longer be needed. If no 
other processes are waiting on the condition, then it could be deleted from object conds. 
These .optimizations would increase efficiency by keeping the size of conds as small as 
possible. However, they will not be performed in the examples here. 

Note that in certain situations, the range of possible values of the parameterizing 
variable t may be quite limited. If this is so, then it might be more efficient to add all 
possible values to the domain of conds initially, and eliminate the need for adding (and 
deleting) new conditions dynamically. This optimization, however, relies on extra 
information that is not contained in the specification but would have to be supplied in 
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addition by the specifier. In aiv actual system, this might be accomplished by having the 
system interact with the user to fimi oat about the range of values of a given parameter. 

In order to signal the conditions contained in an object of type conditions[Tl the type 

must have an iterator "domain" for accessing one by one (in an unspecified order) all values 

of t for which conditions exist. By iterating through these values, all conditions on which 

processes may be waiting are tested. The code for signalling that appears at the end of 

each monitor procedure is: 

for t:T in conditions[T}fdomain(conds) do 

if co7i<j({ionSqueue(conditionsrnSget<conds, t)) a C D (t) 

then coRrft«onisignal(conditions[T]tget(conds, t)h end; 
end; 
This serves to signal a process on any of the condition queues iii i conds whose predicates are 

true. Where there are ^veral different ^bbjects^c^lyp^ c^ 

combinations of gates wfth satisfiabfe qualifying preditatei, then this must be generalized so 

that the conditions contained in atf of them are tested ahd sigrtafled. (ffottce that if the 

optimization mentioned earlier of deleting uhneeded conditions were applied, then the 

implementation of the "donWm*1teritoh^bulct have to function correctly in a situation in 

which conditions could be deleted while the iterator was suspended due to a "signal" 

operation.) 

For an example to illustrate the above discussion, suppose that ihe solution 
specification consists of the following parameterfted entry condition: 
For gate Ip(y> f(y ♦ 1 - iHT**: 
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where variable t is an integer. Then the parameterized quantities count([q(x) I (x - t)] en " r ) 
and count([q(x) | (x •= tyr"') would be implemented by objects of type cour\ls[integer], as 
explained previously, named qentercounts and qexitcounts. They are created conceptually 
containing counts for all possible values of t, with all counts initialized to 0, and are 
updated by "incr" operations in procedures q_enter and q_exit, respectively. 

An object pentry of type conditionsu'nriger] can be used to hold the conditions 

required. The predicate corresponding to the condition for any tg is given by 

counts[(n/«£er]$get(qentercount5, tg) - counts[inftf|¥r]$get(qexitcounts, tg) 

Conditions are added to pentry by the statement 

conditionsbn/*£*r]|add(pentry, y+1) 

appearing at the start of monitor procedure pjenter, which takes the same parameter y as 

operation p. The waiting in procedure pjenter then is accomplished by a wait on the 

appropriate condition, retrieved via a "get" operation: 

if counts[initfger]tget(qentercounts, y+1) * counts[inr«ger]$get(qexitcounts, y+1) 

then conrfirumtwait(conditions[tnr«|«r]tget(pentry, y+1); end; 

The signalling code at the end of each monitor procedure is: 

for tinteger in conditions[infcg?r]Sdornain(pentry) do 

if con<f{fiontqueue(conditionsrinr«£»r]Sget(pentry, t)) a 

countsrinfegerltgetfqentercounts, t) = counts[in/i£?r]$get(qexitcounts, t) 
then conrfitfontsignaKconditionsbntegCTlSgettpentry, t)h end; 
end; 
The overall monitor for this example appears in Figure 5.4. 



- 142- 

Figure 5.4. Monitor for functional paramfterired exampte 

parafun - monitof; 

qenrercounh, qexitcoonls: imtntslinteger}; 
pentry: conditions[tnfc£?r]; 

q_enter = procedure(x:intcger); 

countsUntiger^ftmiafa^tneonii, x>, 

for Vinteger in conditions[inr«|vr]$domain(pentry) do 

ifconditionSqueueicondilionslintegerl&gelfantry, t» A 
<&w\tslm2gftljl^qeht^ 
then conrfi/tcmfsignaKconditionsDntejvrllgettpemry, t»; end; 

end; ""' "■-■■-■' ■ ' ■-" ■"■•'-'■' - '■'■:-:■■ ^ ! ■• ,:i-:,-'rv.;^iic- ■-;-: 
*nd q_enter; 

q_exit «= procedure{x:integer); 

counts[('nr«£¥r]fincr(qexUcounts, x); i 

/or tiinteger in conditions[tnr^r]|domain(pentry> do 
if condition^u^J^ammtt^^^iiaktil t» A 

counts[in;<£«r]Sget(qentercounts, t) - counttfrn;<£*r]tget(qexitcounts, t) 
M<>* conrf*ftentstgrtaK«xid4Uow^ 
end; 
end q_exit; 

p_enter = procedure{y.integer); ~ 

coriditions[inf«g*r]$add(pentry, y+I); 
if counts[i7j/<-^3fget(qentercounts, y*l) * ccHjnts{fitfegw)fget{qexitcoufrts, y*l) 

then condition$wait(condkions[in;<g«r3tget(pentry, y*\\ end; 
/or fc#rt*g*r in €o»Wit*amfo^ 

if conrfi«on$queue(conditions[inf«£«r)tget(pentry, t» A 

countstm/^r]|g^q^B^ceiiirt^ r tt "•* ceu«ti[£nfef*r3tg«(q«xrtcounts r t) 
then conrfirion$signaKconditionsfcnf«£*r]fg«(p«nry, t)>, *nd; 
end; "-' ■ 

end p_enter; 

qertercounts :•= cottnts&titegrrltcreateO; 
qexitcounts :- t»unts^«^|l^e|ttO; . 
pentry :- conditions[fnf<£*rltcreate(); 
end parafun; 
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If the relation R(t, v) that qualifies an enter gate is not functional, then the enter event 
must wait until the entry condition represented by predicate C_(t) is satisfied for all values 
of t such that R(t, v) is true. That is, the entry condition for an activation of p with 
argument vector v is given by the formula 

Vt(R<t,v) ? Cp(t)). 
This is considerably more complex than the entry condition G p (f(v)) for the case where the 
relation between t and v was of the functional form t - f(v), as discussed above. 

As discussed above in connection with parameterized qualifying predicates that are 
functions, information about the range of possible values of the parameters could be used to 
optimize the implementation. Such information would make a much greater difference here 
where the predicate is a nonfunctional relation. In the absence of such information, which 
would have to be supplied by the user in addition Jo the specification, the impkmentation 
to be presented here must work under the assumption that the range of possible values of 
each parameter is infinite. The result, is a severe penalty in both complexity arjd efficiency. 
It will be noted where user-supplied range information could be used to simplify and 
optimi2« the. imple<npntation. 

An assumption is made here that the predicate C p (t) is initially true for all values of t 
That is, it is assumed to be something like 

«ntnt([q(x) | (x •= t)r*~) L - o^t([q<x) [ (x - t)r a X 
rather than 

count([q(x) I (x - t)r tar ) > cwnt([q(x) J (x - OF 1 *). 
If this were not the case, and assuming there are an infinite number of possible values of t 
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satisfying predicate R(t, v), then the entry condition 

V t (R(t, v) t> C p (t)) 
could never be satisfied, since there would always be some values of t (in fact, an infinite 
number) not satisfying the body of the quantified formula. Her* is one example Of where 
information as to the range of possible values of t would be helpful, since in fact t might 
assume only a small number of possible values. ; 1ft* the absence 'of an explicit range, 
however, the range must be assumed to be mfirrite. Analysis to determine What subset of 
the range could satisfy the relation R is clearly beyond the scope of this work. The 
assumption made here appears to be satisfied for all cases of interest, such as the disk head 
scheduler discussed in Chapter 6, and therefore not to be limiting. 

In implementing a solution specification in Which an tnter gate is qualified with a 
nonfunctional parameterized predicate, we again use the type condrtiomlTl The type T by 
which this type is parameterized, however, is not tHetype of the parameterizing variable t, 
but rather the type of the argument vector v, or rnbre precisely of some sub-vector of v. 
The specific subWector chbsert consists of exactly those romponents of V that are involved 
in relation R, which can be determined by syntactic inspection of R. The type of this 
sub-vector will be denoted "vtype". 

Because of the solution specification structure, theft must be a separate condition 
variable for each subset of gates that could apply to a given activation. If processes making 
different activations pass through the same subset of gates, then they must do so in FiFO 
order. This is imple men te d by having the processes wait on the same condition, thus 
ensuring FIFO order. Ill general, two activations pfVj) and p^) wait on the same subset of 
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gates when 

Vt(R(t,Vj) « R(t,v 2 ». 
Ideally, this formula should determine whether two activations wait on the same condition 
variable. However, the logical power necessary to perform this analysis in general is beyond 
the scope of this thesis. Here again, information about the range of parameter values could 
overcome the problem. 

The implementation therefore makes a simplifying assumption, which is that two 
activations of an operation pass through the same set of gates only if the sub-vector of 
components involved in relation R are equal for the two activations. When the argument 
vectors to different activations share the sub-vector to which R refers, though possibly 
differing in other components, then they must pass through the exact same set of gates. 
This means that in the implementation they must wait on the same condition. For this 
reason, there is one condition for each value of the sub-vector of arguments involved in 
relation R. What is assumed here is that two activations with different sub-vectors always 
pass through different, through possibly overlapping, subsets of gates, so that in the 
implementation they can wait on different conditions. This assumption is true for the disk 
head scheduler of Chapter 6, for instance, and where the relation R is something like 

t < x, 
where x is one of the arguments in v. This is because if two values of x are unequal, then 
there exists some value of t that is less than one but not the other. An example of where 
the assumption breaks down is if R is of the form 

t «= absolute_va1ue(x), 
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since x and (-x) satisfy this relation for the exact same set of values of t 

The object conds of type conditionslvtype] is different from the corresponding object 
of type conditions[T] in the case of a functional relation. As before, the object is created 
initially empty, and conditions are added to it dynamically in the monitor "enter" procedure 
prior to the code for waiting. However, since the predicate associated with each condition 
in conds is of the form 

Vt(R(t,T) D C^ 
it is necessary also to iriamtairi a^record of ftiolie values of the parameterizing variable t that 
have occurred, sinice these are the values for wii^CLlfrX w1ittH 7 §f assumption is initially 
true, may have become false. This is accomplished by saving the set of all relevant values 
of t in an object "tset* of type setT/fl (whef£ f is again iSi'tyjfieiof % Th£ Object tset is 
initially created as the empty set. Elements are aetded 'loTEfirsefc ' : kif the Insert* operation. 
An "insert" operation must be performed in eacti monitor procedure in Which quantities 
involved in the predicate C D (fr are updated. ^There is alsb' ait ftefltor "elements" for 
accessing the elements of the set. ^ 

As was the case mentioned earlier for type conditionsfTl information from the user as 
to the range of possible values of t would permit an optimization to be performed with 
respect to the object tset. If the range is relatively small, then all relevant values can be 
inserted into the set beforehand. This would eliminate the need to dynamically insert 
values. Note that another optimization mentioned in connection with conditionsTT], that of 
deleting elements when no longer needed, cannot be applied to tset, since any value of t that 
has occurred may be relevant and must therefore be saved. 
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The code in procedure p_enter(v) for testing and waiting on the condition in object 

conds is given by: 

for t:T in set[T]$elements(tset) do 
if R(t,v) a (-C p (t))M*n 

con<frltontwait(conditions[vtype]tget(conds, v)); end; 
end; 
This code implements waiting on the entry condition- 

V t (R(t, v) D C p (t)). 

The required condition is added to conds by the statement 

conditions[vtype]|add(pentry, v>, 

at the start of the monitor procedure. 

Notice that the "elements" iterator may be suspended in the middle of execution due to 
the execution of a "wait". While it is suspended, new values of t may be added to tset by 
other monitor procedures. The iterator must be implemented so as to function correctly in 
such a situation. 

Signalling at the end of each monitor procedure is complicated. The signalling code 
must iterate through all values of z (a sub-vector of v) in conds, for each one testing 
whether its predicate is true by iterating through all values of t in tset This code involves 
an iterative loop within an iterative loop, with a "signal" operation performed at the 
completion of the inner loop if all values of t for which R(t, z) are true satisfy the predicate 
C p (t). (We take the liberty of saying "R(t, z)" rather than "R(t, v)", since i contains all the 
components of v that are involved in R.) The code is of the form: 
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for z:vtype in cooditi6ns[vtype3klomain(conds) do 

if c0nrfmon9queue(conditions[vtype]Sget(conds, r)) t hen 
vbJboolean :•* true, 
for t:T in setTTJIelementsftset) dp 

ok -.-false; end; 
end; 

ifck then am<taftmisignaKconditions[vtypettge4<conds, z)); end; 
end; v "" "' "'"''*'' 

*nd; ;■ ... - 

The boolean variable ok keeps track of whether the predicate CJt) is true for alt values of 

t for which R(t, z) is satisfied. If ok is still true after the end of the inner loop, then 

V t <R(t, z) D C p <t», 

is true for the given value of z, arid therefore the condition should be signalled. Notice that 

if there is a process waiting oh Che condition queue for i, there must be at least one value of 

t for which R(t, z) Is truet because otherwise there would have been no reason for the 

process to have performed a "wait". As before, in a situation in which there is more than 

one object of type conditions^ the conditions in each such object must be tested and 

signalled by code of the above form. 

As an example, consider a solution specification consisting of the condition: 
For gatetpCy) I (yVt)f rt * r : 

countflq(x) f (x - t)]"**)"- cou«t(fq(x) |(x - t)T**) 
where variable t is an integer. Then as in the previous example, count([q(x) f (x - t)!*"**') 
and count([q(x) | (x - t)] ,xH ) are implemented by objects of type cbuntsDnftg«rl named 
qentercounts and qexitcounts, respectively. An object pentry of type conditionslintegerl is 
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used to hold the conditions requiwUhe single argument* serving as the sub-vector of v 
involved in relation R. An <tojfitt--ti*--&ti&4H*M*lrt+*ta tiie values of t. to which 

values are added by the statement 

set[mf<r#rr]*insert(pentry. xh 
in monitor procedures q_enter and jjysxfr TMewde for watting in procedure p_enter is 

given by 

far vinteger in set^^«r^lemefltsj[tset) do 

if y < t a countsunff^HgeKqentercounts, t) * 

counts[fn/*£rr)tget(qexitcounts, t) 

theft ,,,. _.y ,-,; .. .,;,,;. .,■,'.,;', 

conrf«tontwait(conditionsiifi«^«r]|get(pentry. v))-, end; 

end; ...._, ; _ 

As before, the required condition is added to pentry at the start of the p.enter procedure by 

the operation 

condiuons{fofe|irrttadd(pentry, y}, 

The signalling code at the end of each monitor procedure is: 
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for vintegei in condUions[inf^er3ldorrUilh(pentry)«to 

okibooiean :■ frue; 

/or tinteger in set[tnfe|*r]Selements(tset) rfo 

1/ z < t A ctnmts&n/*£<>1tget<qentercounts, t) * 

^eaum«B»i/(^m%«^j«w»ynt$* 4),-. 
M«n ok -."foist; end; 
end; 

if ok rAen ccmriir{ontsignaKcondition^n/<g'^r3tget(pentry, i)>. end; 
end; 
end; ' ' "•"''''" ^ '' 

The monitor for this example appears in Figure 5.5. 

A number of examples of the translation techniques discussed here appear in Chapter 
6. These examples actually illustrate the entire synthesis process, starting with problem 
specifications of the type described in Chapter 2, proceeding to the construction of 
equivalent solution specifications via the method presented in Chapter 4, and finally 
translating these solution specifications into monitors as discussed in this chapter. In 
particular, the last example of Chapter 6, the "disk head scheduler", illustrates the 
implementation of qualified gates involving parameterized predicates. 
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Figure 5.5. Monitor for nonfunctional parameterized example 

paranon = monitor; 

qentercounts, qexitcounts: counts.[integer\ 
pentry: conditions[integ*r]-, 
tset := setlintegerln 

q_enter = procedure(xinteger); 

counts[inr^r]8incr(qentercounts, x); 

set[integer]&insert(tset, x); 

for vinteger in conditions[inte£er]|domain(pentry) do 

if condit ion$queue(conditions[inf«g*r]jiget(pentry, z)) then 
ak:boolean := true; 
for tinteger in set[integ*r]felements(tset) do 

if i<t A counts[in*tger]8get(qentercounts, t) * 
counts[inf*g*r]tget<qexitcounts, t) 
then ok -."false; end; 
end; 

ifck then conrfatontsignaKconditionsLinrei^ltgettpentry, z)); end; 
end; 
end; 
end q_enter; 

q_exit = procedure{xinteger); 

counts[inf«g»r]$incr(qexitcounts f x); 

setUntegerlfc insert(tset, x>, 

for vinteger in conditions[inr*g*r]tdomain(pentry) do 

t/conrft«on$queue(conditions[inr<^r3Jget(pentry, z)) then 
okiboolean -.- true; 
for tinteger in set&nf*g*r3felements(tset) do 

if i<t a counts[infeg?r]Sget(qentercounts, t) * 
ccHintsbntejvrltgetfqexitcounts, t) 
then ok := false; end; 
end; 

if ok then conrftriontsignaKconditionsbnr«fer]tget(pentry, z)>, end; 
end; 
end; 
end q_exit; 

p_enter * procedures-integer); 

conditions[tnfeger]$add(pentry, y>, 

for tinteger in set[tnteg*r]felements(tset) do 

if y < t a countsftnfe|vr]Sget(qentercount5, t) * 

countsUnttg<r3Sget(qexitcourits. t) 
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then con</trton|wait(conditions[tn^er]|get(pentry, v)); end; 
end; 
for vxnteger in conditions[infe£er]Sdomain<pentry) do 

ifconditionfyueue(con6tlimsUntegeryi%t#{j^tzy, ifixhen 
ok-.boolean :- true; 
for tUnteger in set[tnf*£*r]telements(tset) do 

if z <t a countsfcnf^rjtge^qentercounts, t) * 
countsDnr<|-CT)^^9?xi6coMoU, t) 
then ok :- false; end; _- ;i . ; .. ; 

t/ok then wn^wnlsigpa|^nditionsD^<^«rKget(|>«^tr)f, z}); end; 

<nrf : , . /; ,,. ..'. _ _. ,,..; ..., ; .:. , H: ,, r ,^V 

*nrf; 
*nrf p_enter; 



qentercountt :- cmt^^te^0S^^t; 
qexitcounts :«= countsttnfcg*r3tcreate(); 
pentry :- conditions[inre£*r]Screate(); 
tset :- ^nteg&lfc^ieQi 
end paranon; 
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Chapter 6 
Complete Examples of Synthesis 

6.1 Introduction 

This chapter presents a series of examples of the complete synthesis method. Each 
example starts with a problem specification, and derives an equivalent solution specification 
via the method presented in Chapter 4. This solution specification is then translated into a 
monitor implementation in the manner outlined in Chapter 5. The examples chosen for 
this chapter are problems that commonly are addressed in technical literature on 
synchronization. These are the bounded buffer, two different versions of the readers-writers 
problem, with writers' priority and alternating priority, and the disk head scheduler. 

6.2 Bounded buffer 

The first example in this chapter is the specification of example 9 from Section 2.7, the 
"bounded buffer". The problem specification given in Chapter 2 is repeated here, to be 
denoted bb: 

(dep^** => rem i eBtar ) A (remj MH => dep i+N ,n " r ) a 
(dep^* => dep^,- 1 ") a (rem i wH =» rem i+ ,' nUr ). 
The specification bb consists of four conjuncts, and the solution specification is constructed 
by analyzing each conjunct separately. Since each individual conjunct is quite simple, the 
analysis is straightforward. For purposes of reference, the four conjuncts are denoted bbj, 
bbo, bbj, and bb^. 
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The first conjunct to be analyzed is bbj, 

(dep^ ^tentj^f). ;, 
This conjunct specifies that the i-th "deposit" activation must finish before the i-th "remove" 
activation can start. This constraint ensures that no attempt is ever made to remove a 
message from the buffer before it has been deposited in. Since there are no argument 
constraints in the conjunct, the first step in the analyses is the identification of which event 
expressions are mentioned. The set of event expressions in lb* conjunct is given by 

Evexpfob,) - {dep^. rem i wtof }. 

The next step is to construct the possible orderings among the events represented in 
the set Evexp(bbj). With just two such events, only two orderings are possible: 

(1) (depj** ^ remi*****) 

(2) {rem/ 1 "" => depf**) 

In evaluating whether each is valid or invalid, it is obvious that the first is valid, white the 
second is not. Equally obvious is the fact the the offending event in ordering (2) must be 
the first event, namely rem i * m * r . This means that a solution specification condition must be 
derived for the rem• n, • , ' gate. 

Characterizing the state at each event in the rem* M * r event class,, one obtains 
characterizations Cj and eg for event remj*" , * f in orderings (I) and (2X respectively: 

c,: 3 i (couMfctep"*) > i <\ cowit(rem wter ) < i) 

eg 3i(count(dep" ,rt )<i a c^p^(refl|^ l • , ) < i) 

With only one valid ordering, the disjunction of valid ordering characterizations D v is 

simply cj. Similarly, the disjunction of invalid ordering characterizations Dj is c^ The 
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preliminary condition, given by (D v a (-• Dj)), then becomes 

3 i (count(dep" lit ) > i A count(rem ,n,er ) < i) a 
V i (count(dep"" 1 ) > i v count(rem ,nUr ) > i). 
which reduces to 

3 i (countfaep"") > i > count(rem en,,r )). 
The quantified variable i can be eliminated, resulting, in the simplified formula 

count(dep" ,rt ) > count(rem• n, • , ). 
When tested, this condition is found to satisfy the single valid ordering, ordering (1), 
showing it to be the correct condition obtainable from conjunct bbj. 

Each of the other three conjuncts can also be analyzed quite easily. The second 
conjunct is bb2« 

(rem^" =» dep i+N - nUr ), 
This prohibits more than N consecutive "deposit" operations without at least one "remove" 
operation, preventing overflow of the buffer. The set of event expressions for this conjunct 
is 

Evexp(bb 2 ) - {remj""". dep i+N ,nUr }. 
The two possible orderings are 

<l)(rem i Mit =>dep i+N Mtar ) 
(2) (de PitN ,nUr => remi'"") 
Of these, the first is valid, while the second is invalid, with the offending event in (2) being 
de Pi*N* nUr - ^ condition must be derived for gate dep ,lrt,r . 
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The state characterizations fbV evertf depj^*^ in ordering* <l) and (2>, respectively, 
are given by Cj and eg 

cj. 3 i (countO-em - **)* i a count(dep* ,,i ') < i«N) 
c 2 : 3 i (count<rem"'" t ) < i a count(dep*" t * T ) < i*N) 
The preliminary condition, (D y a (-» Dj)), is equal toftj^f*^)): 

3 1 (cow^rem***) 2: i A coa«l^e^ M, ^4 f*N) a 
V i (cwmtrem**)^ i v countfctep* - *) > UN), 
which simplifies to ■■♦■■" 

cwntfftrri**") > co8Ht(d«p" ,, *7-K. 
This is the correct solution specification condition for conjunct bbo- Notice that variable N 
in the above formulas is treated as a constant, since it is the parameter to the abstract data 
type itself. For this reason, it is not quantified and cannot be eliminated as variable i is. 

The last two conjunct* are identical, except that bb$ applies id operation "d*p* arid 
btr^. to operation "rem". Therefore, whatever condition " ir obtained frorrT bb^ ; for gar* 
dep* n,,r applies in corresponding form for rem*" tor due to bb^. The constraint specified by 
each is that activations of the given operation must W nNttua'Hy exclusive and must proceed 
in first-come-first-served order. This prevenu interference by c o ncur r en t activations of the 
same operation manipulating the stmt local data, and guarantees that messages are 
deposited and removed in the proper order For ©ahjunct bbj, 

Evtt J Kbb 3 )-fd«p | * -, ;'a^i 4 j- , nr 
The two possible orderings arc 

(l)(dep i * ,ri, =*dep ul - ,w ) 
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Ordering <1) is valid, but <2) is not The effeiidtag event in (2) is d*p 1+ |' nU \ so a condition 
is required for gate dep*"*"*. 



The state characterization* for event dep^,**" in^ pcderings (I) and (2), respectively, 
are given by C| and c 2 : ...... ,.•><;, ■,--.- T - :s v.vt ■ ■, > . 

fy 3 i (cou^ideo"*^ 2UL a count^dep - "*") < i+l> 

The preliminary condition, (D v a (- D^ #j given *y {c^ a £fcgf^ , * , 
3 i (countfdep"*) > i ^.©ajw^din/!^^ A 

This reduces to simply , r 

couB^dep-^-couatdcUp^). 
which is the correct solution specification wdiUon for conjunct bbg. Analogously, the 
correct condition for bb^ is , ifl ,., 

count^rem" - *) - count<reni # "*) 
for gate rem ,Btar . 

The overall solution specification for specification bb is constructed by conjoining for 
each gate the conditions obtained separately from the individual conjuncts. This obtains 
the following overall conditions: 
For gate dep , * , * r : 

count(rem™^>c«unt(dep• ,,ta, ) N A countfdep*"**') - count(dep Mit ) 
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For gate rem* nUr : 

counUdep'*'*) > coun^rem**") a countfrern***) * countO-em*"*) 

The monitor to implement this solution specification must have four integer variables, 
depn, depx, remn, and remx, to represent the quantities kWihHdep^ 1 ^, couht(dep* ,,,t ), 
count(rem' n,,r ), and count(rem• x ' , ). There also must be two condition variables, depentry 
and rementry, corresponding to the entry conditions for gates dtp*"'*' and rem* n, * f , 
respectively. The boolean predicates associated with these conditions are 

depentry: remx > depn - N s a depn «* depx • 

rementry: depx > remn A 5 fefrin*'remx 
Since the request events for the two operations are not used in the specification, there is no 
need for procedures to implement the corresponding gates. The monitor for the bounded 
buffer is presented in Figure 6.1. Since <he intention ir for* the monitor to be contained 
within the type module for the abstract typetiafrerff 1 *), the* ^iriibfer^ inside the monitor is 
bound to the parameter of the type. 

6.3 Writers' priority database 

The second example in this chapter is a problem that was introduced in [Cou71]. The 
data abstraction in question is a database, on which two operations are defined: "read" 
accesses the database without changing it at all, and "write" updates the database. In order 
to ensure consistent accessing and updating, these two operations must obey the 
"readers-writers" property embodied in example 3 of Section 2.7. In addition, the scheduling 
policy desired is for activations of operation "write" to have absolute priority over those of 
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Figure 6.1. Monitor for bounded buffer 

bb - monitor; 

depn, depx, remn. remx: integer; 
depentry, rementry: condition; 

m 

depjenter - procedure; 

if (remx < depn - N v depn * depx) then conditiont wait(depentry); end; 

depn :« depn ♦ 1; 

choose 

conrfifi07iSqueue(depentry) a remx > depn - N a depn - depx: 

conrfi/ionlsignaKdepentry); 
con<titionfqueue(rementry) a depx > remn A remn - remx: 
condittonisignaKrementry); 
end; 
end depjenter; 

dep_exit = procedure; 
depx :•= depx ♦ 1; 
choose 

conrftfiontqueue(depentry) a remx > depn - N A depn - depx: 

conrft/tonSsignaKdepentry); 
coiutittontqueuefrementry) a depx > remn a remn - remx: 
conWitiontsignaKrementry); 
end; 
end depjexit; 

remjenter - procedure; 

if (depx < remn v remn * remx) then conrftftontwaiKrementry); end; 

remn :- remn ♦ 1; 

choose 

conttirionfqueuefdepentry) a remx > depn - N a depn - depx: 

conttotontsignaKdepentry); 
con<tiftoniqueue(rementry) A depx > remn a remn - remx: 
coTutiftonSsignaKrementry); 
end; 
end remjenter; 

remjexit - procedure; 
remx :« remx ♦ 1; 
choose 

conttitfoniqueuefdepentry) a remx > depn - N a depn - depx: 

concfrttonSsignaKdepentry); 
conrf««mlqueue(rementry) a depx > remn a remn - remx: 
conrfirfonfsignaKrementry); 
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end; 
end rem_exit; 

depn, depx, remn, remx := 0, 0, 0, 0; 
end bb; 
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operation "read", in order to ensure that each "read" operation accesses the most current 
version of the database. Therefore, to the "readers-writers" specification of example 3 must 
be added an instantiation of the priority specification embodied in example 4 of Section 2.7. 
The overall specification is the following, to be denoted wpdb: 

((writej""" => writej ,n,ar ) D (write i wi * => writej ,n,,r )) a 
((write^ 1 * => read k an, " r ) v (read k Mit => write i " n,e, )> a 
((write i re< ' " s, => readj entar ) 3 (write i • n,e, =* readj en,er )). 

The specification contains three conjuncts to be analyzed. Of these, the third conjunct 
has already been treated in detail in Section 4.2, with the names "p" and "q" used for the 
operations instead of "write" and "read". By the analysis in that section, this conjunct 
contributes the condition 

count(write r " qurtt ) - count(write*" taf ) 
to the gate read enter . 

The other two conjuncts of the specification remain to be analyzed. They will be 
referred to as wpdbj and wpdb 2 , respectively. The first conjunct wpdbj is 
((writei entar => write;"*") D (mitef** =» writej #ntor )). 
As with the bounded buffer example, there are no argument constraints in this or any other 
conjunct. The set of event expressions contained in the conjunct is 

Evexp(wpdbj) - {write i * l,, * r , writej*"*, vtrite^* mr }. 
There are three possible orderings among these three events: 

(1) (write i " ,,,r =» write!'** =* writej• ,,, • , ) 

(2) (writej• n, • , =* write i • B, • , =» write!"*) 
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(3) (write i *"'* r '"=> witef*" => writej***) 
When ordering (I) is substituted into the conjunct wpdb,, the result is the formula (TRUE O 
TRUE), or simply TRUE, so that ordering (1) is valid! Ordering (2) is also valid, since it 
evaluates wpdb, to the formula (FALSE 3 FALSE), which similarly reduces to TRUE. 
Ordering (3) substituted into wpdb, evaluates to (TRUE D FALSE), or FALSE, so that 
ordering (3) is invalid. 

Comparing invalid ordering (3) with the valid orderings (1) and (2), the longest 
matching prefix is the one-element sequence [write,*'**'! matching ordering (1). The 
offending event in (3) is therefore the event following this prefix, which is write j *"'* r . This 
means that a condition must be derived for the write™*' gate. 

The state must be characterised at the point of each event in the write*"'" class that 
either occurs within a valid ordering or is the offending event in an invalid ordering. 
There are five such events, write,*"**' and write,*"'*' in each of the two valid orderings (1) 
and (2), and writej*"'*' in invalid ordering (3), where it is the offending event Denoting the 
characterization at event write,* w * v in ordering (1) as'cj,, etc: 

c„: 3 (i, j) (count(write* n ** r ) < i a countfwrite*"'*') < j a cdunt(write* ,ti ') < i) 
c,j: 3 (i, j) (count(write* n, * r ) > i A count(write* rti O < j A count(write* xff ) > i) 
c 2 j: 3 (i, j) (count(write* M **) < i a count(write"**) < j a count(write" ,it ) < i) 
c 2i : 3(i,j)(count(wr»e* n, * r )<i A count(write* ,,ilw t > j a count(write•' ti, ) < i) 
c 3j 3 (i, j) (countfwrite*"**') > i a c*unt(write*"** r ) < j a countfwrite"") < j) 
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The four characterizations from the valid orderings are disjoined to form D v : 
3 (i, j) ((count(write" nt " r ) < i A couiit(write" xit ) < i) v count(write" nUr ) < j) 
Since there is only one invalid ordering, the disjunction of the invalid ordering 
characterizations Dj is simply C3;. The preliminary condition is given by (D v A -• (Dj»: 
3 (i. j) ((count(write' n,,r ) < i a count(write* xrt ) < i) v count(write* n,,r ) < j) a 
V (i, j) <count(write' n *' r ) < i v count(write' ntar ) > j v count<write' xrt j > i). 
This reduces to 

V i (count(write* ntor ) < i v count(write* xrt ) > i), 
which in turn simplifies to 

count(write• nt " , ) * count(write" x ''). 
When this condition is tested for both write* 1 *" events in each of the two valid orderings, it 
is found to be satisfied in all cases, showing that it is the correct condition. 

The other conjunct in the specification is wpdb2: 

((write/"* => read^") v (read,/"* =* write/ nU, )>. 
The set of event expressions contained within wpdb2 is given by 

Evexp(wpdb2) - {write/" ,,f , write/"*, read k " n,,r , read,/"*}. 
There are six possible orderings of these four events: 

(1) writej"" ,ef =» write!™* => read,/"'" =» read,/"* 

(2) read,/"'" => read,/"* => write/ n,€f =* write/"* 

(3) write/" 1 " => read,/ 1 *" => write/"* =» read,/"* 

(4) write/ nt,r =» read,/ n, " , =* read,/"* =* write/"* 

(5) read,/"'" =» write/"'"' =» read,/"* => write/"* 
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(6) read^*"** =* wrftej^ ^ wrlte^^ tod^ 

When wpdb 2 is evaluated for each of these ordering*, the results for orderings (1) and 
(2) are (TRUE v FALSE) and (FALSE v TRUE), respectively, each of which equals 
TRUE. This means that orderings (1) and (2) are valid, For each of .the other four 
orderings, the resulting formula is (FALSE v FALSEX wMc^eauals FALSE, showing each 

•-■:■:•,•.■■■ . ; ' " \:.,^m v i > ( v -'' '?ii:v-'>Sf?ii-j-jMi; ,:. ■- 

of these orderings to be invalid. 

The next step is^d rderrtify th* offending event in each of the four invalid orderings. 
Both orderings (3) and (4) match valid ordering (I) as far as the %% 'evl&t, write/****! Tne 
offending event in each is nie setbnd"ev^t%hl*W^flttP cases is read^". Similarly, 
orderings (5tewid («)bdth mat*%rderihg (2| 'aVftf riffle Wat Bill; rea 1 ^,**", so that the 
offending event l*»each ca« is wfkef^^^ Solution 

specification conditions must be derived for two gates, read*" tor and write*" Ur . 

In order to derive the condition for gate wad^^'it is necessar/ to characterize the 
state at certain events in the read*"*" class. The events in the Cfess occurring in valid 
orderings are the read^* event* W ordering* (1) and (2). The offending events in the 
class are the occurrences of Hadj^"""* In ordering* ffl lk$ W^^benoting these 
characterizations as Cj r ,$e^efc, tney are: *'-' .5 *'^ ' * ; 

c Ir : 3ft *) ^»»mt(wr«e* ,,,w ) i i A coUBt(wrtfe*'*) £i a 

eouiriCread***) <*k a oart^read**)^ if 

cgn 3& i) ^n^wrle*^ Wa eo*int(wr*e***) < i a 

'"* '• - s e^nffread* 1 *) ! <ir a" C9**ii(feia*^«%--' 
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c 3r : 3 (i, k) (count(write an, * r ) > i A count(write" trt ) < i a 

count(read ,n,,r ) < k a count(read* xH ) < k) 
c 4r : 3 (i, k) (count(write ,ntor ) > i a count(write" it ) < i a 
count(read ,nUr ) < k A count(read ,,cit ) < k) 
The two disjunctions are given by D y = (c Jr v c 2r ), and j - (c 3r v c± r Y 

D v : 3 (i, k) («count(write" rt,r ) > i A count(write" rt ) > i) v 

(count(write ,nUr ) < i A count(write** it ) < i)) a 

count(read ,nto ') < k A count(read Mit ) < k) 

D- 3 (i, k) (count(write* n,w ) > i A count(write Mit ) < i a 

count(read" Btaf ) < k a count(read" ,H ) < k) 

The preliminary condition is formed by the expression (D v a (-• D^)), 

3 (i. k) (((count(write* ntar ) > i a count(write #,,it ) > i) v 

(count(write' ntor ) < i a count(write** M ) < i)) a 

count(read wrt " r ) < k a count(read* xit ) < k) a 

V (i, k) (count(write w,tor ) < i v count(write* xM ) > i v 

count(read" lrt *0 > k v count(read' xit ) > k). 

This can be simplified to 

V i (count(write• ,rt • , ) < i v count(write Mil ) > i). 
which in turn is equivalent to 

countfwrite""'") - counUwrite"''). 
This condition satisfies both valid orderings (1) and (2), and so is correct 
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Because of the symmetry of (he specification wpdbg, apd therefore of the orderings, 
the derivation of the condition for, gate write*" 1 ** is completely isomorphic to the above 
derivation. Rather than repeat essentially the same derivation, I will simply state the result, 
that the condition for gate write*"'" as a result of this conjunct is 

count(read* Dter ) - c«unt<read* l,a ). 

The overall solution specification for specification wpdb is constructed by conjoining 
the conditions from the individual conjuncts. The composite conditions are 
For gate read'"'*': 

coullt(write r • , ' "* , ) - count(write* lrt * r ) a cdunt(write*" , * r ) - count(write* llH ) 
For gate write* nt,r : 

count(write«" , * r ) p cou«tCwrite* 1ti< ) a c©u»j$read* n, * r ) - colmt(read• ,,i, ) 

In the monitor into which this solution specification is translated, there must be integer 
variables wr, wn, wx, rn, and rx, representing count(write r ^ urt '), count(write* nUr ), 
count(write" Irt ), count(read* nl#r ), and counKread**"), respectively. There must also be 
condition variables writeentry and readentry corresponding to the conditions in the solution 
specification. Their associated boolean predicates are 

readentry: wr - wn A wn ■ wx 

writeentry: wn - wx A rn - rx 
Notice that count(read r * qu "* 1 ) does not appear in the solution specification, so that no 
variable is needed for it, and thus a procedure readj-equest is not required. The resulting 
monitor appears in Figure 62. 



■ ^Sjg^s^-^S^^^ 
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Figure 6.2. Monitor for writers' priority database 

wpdb ■= monitor; 

wr, wn, wx, rn, rx: integer, 
readentry, writeentry: condition; 

write_request «. procedure; 
wr :- wr ♦ 1; 

choose ,' .. -,- ,.. ,, v;":-,- ,..■>.,.--■■■ '■-•s--;- , , : - 

c(m^r<<mtqueue^ac^pii^^^ !? j|^^;^^.. wn - wx: 

condiitonfsignaKreadentry); 
conrfiHonfqueuetwriteentry) a wn - wx a m - rx* 
condttiwtlsignaKwrtteentryX 
end; 
end writejrequest; 

writejenter - procedure, 

iftm*wx v m*rx then amdirten$wait(writeentry); end; 

wn :- wn ♦ 1; 

cAocue 

cond/tfontqueue(readentry) A wr - wn A wn - wx: 

conditontsignaKreadentry); 
c<mdtttonfqueue<writeentry) a wn - wx a rn - rx: 
cwuttttonJsignaKwiiteentry); 
end; 
end writejenter; 

writejextt - procedure, 
wx :■ wx ♦ I; 
choom 

c<mdt/«m|queue(readentry) a wr - wn a wn - wx: 

«mdifienl»ignai(readentry>, 
c<mdttfcmtqueue(writeentry) a wn - wx a rn-rx: 
c<mdtttonfsignaK*Ttteen«ry); 
end; 
end writejexit; 

readjenter - procedure; 

if wr * wn v wn * wx then amdttieniwaitfjeadentry); end; 

rn :- rn ♦ I; 

cAooj* 

condtttoniqueue<readentry) a wr - wn A wn - wx: 

condirtontsignaKreadentryV, 
condi#oiiiqueue(writeentry) A wn - wx A rn-rx: 
condaieniHginKwriiecntrjh 
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end; 
end read_enter; 

read_exit = procedure; 
rx := rx + 1; 
choose 

co7id£fion$queue(readentry) A wr = wn A wn «■ wx: 

conrfirjonSsignal(readehtry); 
conrfjfJonSqueue(writeentry) A wn = wx A rn » rx: 
coTirfifiontfsignaKwriteentry); 
end; 
end read_exit; 

wr, wn, wx, rn, rx := 0, 0, 0, 0, 0; 
end wpdb; 



169 



6.4 Alternating priority database 

The next example is a variation of the previous one. Again the data abstraction is a 
database, with operations "read" and "write" obeying the "readers-writers" property. In this 
case, though, the relative priority of the two operations is to alternate, so that in a situation 
in which activations of both operations are being continually requested, the result is that 
first a single "write" activation executes, then all waiting "read" activations, then the next 
"write", etc. This scheduling policy is the one followed by the readers-writers example in 
[Hoa74], and is referred to as the "fair database" in [Gre75l 

The specification for the "alternating priority" database is given by: 

((write i ,n1 " ==> writej"" tof ) o (write^ => write^")) a 

((write^* => read k enUr ) v (read k " H => write i ' ntar )) a 

((write^" =» readj request => write!"*) 3 (read^" ==> write i> ,* ,tar )j a 

«write i rw ^« l => ready"*" 81 =* write i # " ,-f ) 3 

3 m <readj'• qu ■ ,, =* write^ =* read^ - *)). 
The first two conjuncts express the "readers-writers" property and are the same as for the 
previous example wpdb. The analysis of the previous section need not be repeated here. 
The last two conjuncts state the "alternating priority" property. The third conjunct apdb 3 
requires a "write" activation to wait to enter until all "read" activations that were requested 
during the execution of the previous "write" have done so first. The fourth conjunct apdb 4 
prevents an activation of "read" from entering until an activation of "write" has exited, 
assuming that there is at least one "write" that is waiting at the point at which the "read" is 
requested. This prevents new "read" activations from continually entering. Solution 
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specification conditions must be derived Tor these two conjunct*. 

The first conjunct to be analyzed is apdbj: 

((write i ,n, * f =* readj' wrtt a=* write i " ,H ) 5 (readj•" , * =* wrlte i+ ,• n, • , )) 
The set of event expressions in the conjunct is 

Evexp<apdb3) - {write-**'*, writej***, wrrte^j* - *, readj*^"^, readj* w,,r }. 
With these five events to be ordered, there are eighteen possible orderings. They appear in 
Figure 6.3. 

When each of these orderings is used to evaluate the specification apdbj, orderings (1) 
through (15) are found to be valid, while orderings <16) through (18) are invalid. Since 
ordering (16) matches ordering (1) through the ftotthre* events in each, the offending event 
in (16) is the fourth event write i+ |•" , * , . Each of the other two invalid orderings (17) and (18) 
matches orderings (1) through (3) as far as the first two events, s6 the offending event in 
each is the third event, also wrhe i+ j w,tor . This means that a condition must be found for 
gate write' n, * r . 

The characterization of the state at the point of the offending event virite^ 9nX * r in 
ordering (16) is given by: 

3 (i, j) (count(write• ,rt • r ) > i a count(write ,rt * r ) < (i ♦ 1) a count(write** rt ) > i a 
couBt(read" qurt ') > j a couBt(read• l,, • , ) < j). 
The characterizations for orderings (17) and (18) are identical, namely 

3 (i, j) (count(write ,B,#f ) > i a count(write* rt,f ) < (i ♦ 1) a count(write* Ka ) < i a 
count(read f#qM * ,t ) > j a counKread 01 ^) < j). 
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Figure 6.3. Possible ordering* for apdbj 

(0 write 4 ' n,w => read/*^ *=*mto:f* ^m&g** r ^write M ~*» r 
(2) write i * B, * r => readj r *^ -1 =» nadf*" «■» writej*"* =* wrlte w ,-w 
(3> write^ - ' =» readj ,fq, * , * »* r«adj ,, ***'» f#i^ + i* ,to * «4 wriie i wil 

(4) wr itejf^ «» wiref* «* mAF**** "** t*a&f#* «*' W*ltej; j*"* 

(5) write i " Btar =* writei™* ■«* mAp**$ •^twdte|;i^ r »** tea*j p ^ r 

(6) write i ^ w ^write i ^^write| rf f^^l^j r ^^^r«adj* rt-r 

(7) ready"""" 8 ' => read;""*? ,=» wrttej" 11 ^ =* wrfe^*** =* ■ m ^ t iA^ m 

(8) read:'""""** => readj"^* ** write/"*^ ■» wriie i ,i"" , " r =* write i ""' 1 

(9) read i r " qu " rt =» write i •" to, =* read,"** -» write,*"* =» write. V" 1 " 

(10) readj f *^ rt =* write i "" tar =* read." - " =► write^""*"' =* write!™* 

(11) readj r " q ' , " rt =» writej*" , * f =» wrte j4 |* ,-,r =» readj*^ *♦ writej"** 

(12) readj**^ - =* writei*"'* *=» wrtfe i ^ i '*' ** Wtte/** "==» readj*" 1 * 

(13) readj r " qM "* t s=* wrfte i * , ' ,r *=» wrlttj** -» readi" - " 1 =* wrttej^" 1 " 

(14) f*ad/* , ' M " ,t => write i , * r ** wfltajW 1 *» wrile i+ | , ^ w "<** ready*" 1 * 

(15) wrUej*" tor ^ write^i" 1 *"? r* write^ ^ittd/**'*" 1 «=> readj** l * r 

(16) writej"" 1 *' ^ readj'* ,y ^^ Wri^*** =** Frt*!*!^'* ** f&y*? 

(17) write i *" tor =» read| rw ^ =» wri6e i «|** l " , »?-» £**%*** *"* readj*" 1 * 

(18) writei*"** =* readj , ^ M-, =» writej k J•■*• , ■♦ tf^?*" =* write|*"* 
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The disjunction of these two characterizations is equal to'Dj': 

D i: 3 (i, j) (count(write" B, * t > - i a <&uht(read f *****)^ j a coimt(read* n, * f ) < j). 

The state also m*m N ^araaertied for events wrHe^^ ai»dwTtte i4 j wt ' r in each of 
the 15 vafcd orderings. This means that » separate charactertzations must be formed. 
However, rriSny of the characteriiations for different ordering* are identical. In fact there 
are only nine distinct characterizations, which are listed 1 here 

(a) 3 (i, jMcount(write w *' r ) > i a co«iit(write* , * w ) < (i ♦ 1) a co^lnt(write• l,i, ) > i a 

coont(read r ^ u-, )>j a count(read• ,,to, ) > j) 

(b> 3 (i, j) (count(write*" l * r ) > i a cottnt(write*" ,w ) < (i ♦ 1) A count(write" rt ) > i a 

count(read , * ,l *• , ) > j a coi|«j;J[read* ,,tar ) < j) 

(c) 3 (i, j) (ct>unt(write , " Ur ) > i a countCwrite"^ <e (i ♦ |) a count(write ,,rt ) > i a 

coMtiread'T* 1 *) « j A cotim( read*" t * f ) <$ 

(d) 3 (i. j) icoun^wrife*^ <a a eonn^rite* - *) < (i # i> a e©1uti<*Hlt«r , * H ) < i a 

co«nt<r«ad** ,0- *>wj a countfretd* 1 *? VjV V>^ 

(e) 3(i,jX(ciount(write* , ^ , y<i A co^^rSe*"**! <ffi 1) a cotttef(write* ,,w ) < i a 

ct«inV(read rw,, ^» j a count(re«i* rt ' r ) < j) 

(f) 3 (i, j) (coun^write*****) < i a c©uiifl(write* ntar ) < \\ * I) a count( write*"") < i a 

count(read r * ,uW ') > j a cou»t(read*" , * r ) i j) 

(g) 3 (i, j) (count(write ,Btar ) > i a count(write wrt * r ) < (i ♦ 1) a coun^write**'') < i a 

count{read , • , » , *• , ) > j a count<read wrt * r ) > j) 

(h) 3 (i, j) (count(write' M " r ) > i a count(write w ** r ) < (i ♦ 1) a count(write , " rt ) < i a 

coullt{read r • <,urt, ) > j a count(read ,B,,f ) < j) 
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(i) 3 (i. j) (count(write ent,r ) > i a count(write ,n, " r ) < (i ♦ 1) a count(write• , " , ) < i a 
count(read r8, ' u " 8 ') < j a count(read' nUr ) < j) 
The disjunction of these nine characterizations is D y , which reduces to: 

D v : 3 (i, j) ((count(write" nt,r ) > i v count(write MH ) < i) a 
(count(read f • , « ort, ) > j v count<read ,n, " r ) < j». 

The preliminary condition is (D v a (-» Dj)), 

3 (i, j) ((count(write en,,r ) > i v count(write wit ) < i) A 
(count(read ,w ^• , ) > j v count(read ,B,,r ) < j)) A 
V (i. j) (count(write* ntar ) * i v count(read r-qurtt ) < j v count(read ,ntar ) i j). 
which when simplified reduces to: 

count(read rw ^ rt ) - count(read ,n, " r ). 

This condition must be tested for both write wtor events in each of the fifteen valid 
orderings. In doing so, it is discovered that the condition is not satisfied for the following 
events: 

writej* n, " r in orderings 13 and 14 

write^,""*" in orderings 5, 11, 12 and 13 

An event must be found that precedes each of these events, as well as the offending 
event in each of the invalid orderings. The only such event is readj r * ,0-, . The state is 
therefore characterized at this event in each of the orderings in question. In ordering (5), 
the characterization at event readj r,qu— * is: 
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3 (i r j>([count(write• ,rt • , ) • read'****] i i a 

[count(write*" , * r ) • read wqu,rt J < <i ♦ 1) A 

[couIlt(write• ,,,, ) • re*d* ,,w,, 3 £ i a 

[«HiW<reid r ^ urt ') • read***"*} < j a 

[count(rewi w,tor ) • read r ^ M,rt 3 « j)t 

In each of the other valid orderings in question, it is: 

3(i,j)<[cdunt(write w,tor )«read rwn, * t ]<i a 

[count(write ,,,tof ) • read r *^ rt ] < (i ♦ 1) a 

tcount(write•* ,i, ) • read'*^ -1 ] < i a 

[count(read fW ^ rt )«read r *^ ,t ]<j a 

tcount(read• n, • , ) • read'^^'^] < j). 

This means that the formula D y ' is given by the disjunction of these two, or: 

D v f : 3 (i, j) WcounHwrite^*) • read***'*'! £ i a 

[comitfwiie**) » i-tad*"*'* 1 ] fc i) v 

([count(write• n, • , ) • read l * qurt1 ] < i a 

tcount(write ,,,rt ) • r*s& mtt **l < i) a 

[cou»t(write wrt,f > • f*ad r * , " ,t ] < (i * I) a 

[count(read r,qwrt ') • read'"*"* 1 ] < j a 

[count(read w,,r ) • read r •^ u •» , ] < j). 

The characterization at readj r • QU •• , in each of the three invalid orderings is the same, 
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3 <i, j) <&um*t{w&r*) mmA—F*l % « * 
{co*mt<wrtte! M *}* md^^i^i) cA 

This formula is therefore %'. The weakening term is itemed by^ v * a (-» Dy>. 

3(i,j)(([comit(write wte, )«read r ^ M * , ]^i a 
[coun^write^*) • read ,,,| " ,,t l > i) v 
([cottntCwrite^') • read""" -1 ] < i a 

[count(writt*"*) • read**" - *] < i) a 

.... ; •- ,.■ '.- ■;■■.•• : -. ;. ^ xnn a* .-".wens •« n , .. !, '.i.'-.'- ; ;r 

[cou■t(w^ite• i * ,, ) • read ,,,w, * , J < (i ♦ 1) a 

[count{reMi&' m * m *) • read*^* - *] < j a 

I*»u«t(read*^ »«idW , ^4 ,ft aj 

V (i, jy<Oo^wlNrillP ,l *>««ad* - ^^ « i v 

tepM«<wfiie**5«««adffl i,,,, ^l.fltM .« 

[eouat<wr«te** w )«read r ^ w, ^}a<i>l) v 

- • , ( fewiili(i«ea^ 

[«W»lUfWl?'?^| i Wa* , ^!^ft't|)u.:, - 
When simplified, this reduces to: 

[counUwrite* - ") • read w, " ,l *l - ko««t<write M *) m nad—"*! 
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This weakening term is tested in each of the six events in valid ordering* for which 
the preliminary condition is not satisfied. It is found that the weakening term is satisfied in 
each case. Therefore, disjoining the weakening term to the preliminary condition obtains 
the correct condition. The condition for gate write'**^HoM conjunct apdbj is: 

coullt<reaa , *^* , ) - countfread*"") v 
[count(write ,n,,r )« read^^J - UxmntfmtoF*) * ie*<P*"*l 

This condition makes sense intuitively. The first disjunct states that there are no 
unfulfilled requests for activations of "read". The second says that the most recent request 
event for "read" took place at a point at which no activation of "write" was active. 
Therefore, a "read" activation is allowed to proceed ahead of the next waiting "write" 
activation if it was requested during the previous "write" activation. 

There remains conjunct apdb^ to analyze: 

((write i w,wwl ** im&J* fm ***vmHF*') D 

3 m (readj , *^ rt "±* write m ^«^«idf B,,f )). 
Unfortunately, the analysts of this conjunct is even more complicated than that of the 
previous conjunct, owing to- the feet that there are » ^possible orderings of the 5 events 
contained within it. These 30 ordering! aw listed in Figure 6.4. 

Rather than go through the details of the derivation, the complete process will simply 
be summarized. Of the 30 orderings, the orderings numbered (I) through (23) are found to 
be valid. Orderings (24) through (30) are invalid, with the offending event in each being 
readj• ,,, • , . A condition must therefore be derived for gate read* ntar . When the preliminary 
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Figure 6.4. Possible ordering* for apdbj 

<1) read/ 8 " 088 ' ?=» write/"" " 81 => write/ n,8f => write m " B =» readi 81 " 8 ' 

(2) read;' 8 " 088 * => write/ 8 " 0881 =» write/"' 8 ' =» readj 8 "' 8 ' =» write m 8xi * 

(3) read:' 8 " 088 ' =* write/ e " ueS, =» read, 8 "' 8 ' =» write/"' 8 ' => write m 8xrt 

(4) readj , " qu * rt => read: 8 "'"" => write/"" 088 * => write i 8 "' 8r => write^" 11 

(5) read:' 8 " 088 * => write/ 8 " 0881 =» write m 8xi * =* write/"' 8 ' =* readj 8 "' 8 ' 

(6) read/ 8 " 088 * =» write m 8,<it => write/ 8 " 088 ' => write i • n, • , => readj 8 " ,8r 

(7) read,' 8 " 088 * => write m 8xi * => write/ 8 " 088 * => readj 811 * 8 ' => write^"* 8 ' 

(8) readj' 8 " 088 * => write/ 8 " 088 ' =» write m 8xi * => readj 8 " t8r =* write/"' 8 ' 

(9) readj' 8 " 088 * => readj 8 "' 8 ' =» write/ 8 " 088 ' =» write m 8Xi * =* write/"' 8 ' 

(10) readj' 8 " 088 ' => readj 8n,8r => write^"" => write/ 8 " 088 ' =* write/"' 8 ' 

(11) readj' 8 " 088 ' ±> write m 8xit =* readj ,n,8f => write i r8 " u88t => write/"* 8 ' 

(12) readj' 8 " 088 * => write/ 8 " 088 ' => readj 8n,8r =» write m 8xi * ==> write/"' 8 ' 

(13) write m " xrt => read,' 8 " 088 ' =* readj 8nt8r =* write/ 8 "" 88 ' ==» write/"' 8 ' 

(14) write^"" => read' 8 " 088 ' =» write/ 8 " 088 * =* readj 80 * 8 ' =* write/"* 8 ' 

(15) write m 8xit => ready 8 " 088 ' => write/ 8 " " 1 =» write/"' 8 * =* readj 8 "' 8 ' 

(16) write m 8xit => write/ 8 " 088 ' => write/"*" => readj' 8 " 088 * => readj 8 "' 8 ' 

(17) write i r8 *' 88 ' => write^"* => write/"* 8 ' =* readj' 8 " 088 ' =» readj 8 "*" 

(18) write i '*^ rt =» write/ n,8r =» write m 8xi * => readj' 8 " 088 * => readj 8 "* 8 * 

(19) write/ 8 " 088 * =» write| 8n ' 8r => readj' 8 " 088 * => write m " xi * => readj 8n * 8f 

(20) write/ 8 "" 88 * =» write i en ' 8r => readj' 8 " 088 * =* readj 8 "' 8 ' =* write m 8xit 

(21) write i r8 "° 88t => readj f ^ U88t =» write/"' 8 ' =* write m 8xil => readj 8 "'" 

(22) write/ 8 "" 88 * =* readj* 8 " 088 * =» write m * xi * => write/"* 8 * =» readj 8nt8r 

(23) write/ 8 " 088 ' => read:'"" 088 ' ==> write m 8xi * =* readj 8 "* 8 * =* write/"* 8 * 

(24) write/ 8 " 088 ' =» read:' 8 " 088 * ==> readj 8n,8r =* write^"" => write/"' 8 * 

(25) write/ 8 " 088 ' => read:"" 088 ' =* readj 8 "' 8 * =» write/"* 8 * =* write m 8xi * 

(26) write i r8qw88t => readj r " qU881 =* write/"*"* => H-adj 81 * 8 * =» write m 8xi * 

(27) write i rw »° 881 =» write m 8xi * => readj' 8 " 088 * => write/"* 8 * => readj 8,, '• , 

(28) write/ 8 " 0881 => write m 8xil =* read: ,80JI88 ' => readj 8 "' 8 ' => write i • n, • , 

(29) writen,*"" => write/ 8 " 088 * =» readj r ^* 8 * =* write i wrt8T => readj 8l,t8r 

(30) write m 8xi * => write/ 8 "" 88 * =» readj™*^ 88 * =» readj 8 "^ => write i • ,, ' 8, 
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condition is formed, it reduces to FALSE. This is the extreme case of an overly strong 
condition, in that 1 none of the 23 valid orderings is allowed. 

The only event that precedes read i * ,,,w ' in all 30 ordering* « readi"""*". The 
weakening term obtained by considering the state at event readj , *** rt alone is: 
[connKwrite'T^) • read'*^ 1 ] - [count^rae*"*") • read r ^ , " , l 
This condition is satisfied by valid orderings (I) through (20), but not (21) through (23). 
This means that the characterizations of both the current state and the previous state at 
readi™*" 8 ' must be u»ed at the same time to obtain another weakening term for these three 
orderings. The weakening term obtained is: 

fcouBt(Wrke wil ) •^ead ,, *^] < count(wrtte M4 ) 
which is satisfied by each of the orderings (21) through (23). 

The solution specification condition, for gate read*"*" from thu.e©cgunct is therefore 
the disjunction of the two weakening terms: 

tcount(write rw ^ - ') • read , * ,w,,t J - [count(wj-Ue ,l,, ' w ) • read , * ,,,-, ] v 
(Ce«uht(wri^ rt ) • rtad' p, ^ < c^n^wriW"*)). 

Again this condition makes intuitive sense. The first disjunct states that no activations 
of "write" were requested but waiting at the paint at which the 'fead^ under consideration 
was requested. The second says that some activation of "write* has exited since the point at 
which this "read" was requested- One of these must be true -before the "read" can enter. 
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The overall solution specification for specification apdb is given by the conjunction of 
the individual conditions obtained for each of the four conjuncts: 
For gate read" lrt " r : 

(count(write" n, " r ) - counUwrite - "'')) a 
(([coun^write' - ^ 8 ') e read"*^ 81 ] - [count(write* nUr ) read"" "']) v 
([counUwrite"*") • read'"""" 8 *] < count(write* xH ))) 
For gate write"" 1 "': 

(count(write" Btor ) - count(write Mil )) a 

(count(read"" ,8r ) - countfread"**)) a 

((counttread'"^ 81 ) - count(read' ntor )) v 

<[count(write* nt " r ) e read"""" 8 *] - [counKwrite™*) a read™*^ 8 '])). 

The monitor implementation of this solution specification requires three variables wr, 
wn, and wx, to represent the current values of count(write'* q0 " 81 ), count(write" n, * r ), and 
coullt(write"'' i, ), and three variables rr, rn, and rx, to represent the values of 
count(read r " qu " 8t ), count(^ead• ,,t • , ), and count(read"* H ). In addition, three variables are 
required to save values at a previous state: wrrr for [count(write r " qo " 8t ) • read'"""* 81 ! wnrr 
for [count(write" nt " r ) e read M * ,u " 8, l and wxrr for [counttwrite"**) • read'"** 81 ! The values 
of these variables are set in the monitor procedure read_request corresponding to gate 
read r " qua8t by saving the values of the variables representing the corresponding current 
quantities. For instance, variable wrrr, representing [count(write ^ * ,u * , ) • read r * qw " st l saves 
the value of wr, which represents count(write raqwSt ). The two condition variables, and their 
associated predicates, are: 
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readentry: wn - wx a (wr^ ■ wrtf r V wxrr < wx) 
writeentry. wn - wx a fn - rx A (rr - rn v wnrr - wxrr) 
The monitor that is obtained appears in Figure 65. 

6.5 Disk Head scheduler. 

The final example of this chapter is the "disk head scheduler" problem. Actually, the 
specification used here is a simplification of the actual disk head scheduling specification 
that appears as Example 14 in Section 2.7. The reaf disk head scheduler keeps the disk 
head sweeping in one direction tifrtlr all requested accesses in that direction have been 
made, then reverses the direction and repeats. Accesses are made as the requested tracks are 
encountered in the sweep, so that the next track to bl accessed is the one that is closest to 
the currently accessed track in the direction being swept. The simplification here involves 
disregarding the direction in which the disk head is sweeping. We simply wish that the 
next track to be accessed is closest to the currently accessed track of all requested tracks in a 
given direction. The requirement that the disk head swee£ continuously iO-Goe direction 
until no further accesses have been requested in that direction is omitted. This allows the 
specification to be considerably simplified (though it a^Jniroduces the possibility of 
starvation, as noted in Chapter 7). 

We assume here that accessing a disk track is accomplished by means of an operation 
named V on the "disk" <lati type. This operation Ukes a single parameter x of type 
"track^no", glvirig' thevaW#brtfie1rack number befng accessed. Activations of "a* must be 
mutually exclusive, since only one access can occur at a time. The first: conjunct of 
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Figure 6.5. Monitor for alternating priority database 

apdb = monitor; 

wr, wn, wx, rr, rn, rx: integer; 
wrrr, wnrr, wxrr: integer; 
readentry, writeentry: condition; 

write_jequest ■ procedure; 
wr := wr + 1; 
choose 

condition tqueue(rea den try) a 

wn - wx a (wrrr « wnrr v wxrr < wx): 
coTutitfonSsignaKreadentry); 
con<tirion$queue(writeentry) a 

wn - wx a rn = rx A (rr - rn v wnrr «= wxrr): 
conrftttonlsignaKwriteentry); 
end; 
end writejrequest; 

writejenter « procedure; 

if wn * wx v rn * rx v (rr * rn a wnrr * wxrr) 

then conrftt«mtwait(writeentry); end; 
wn := wn + 1; 
choose 

con<fitionSqueue(readentry) A 

wn - wx a (wrrr - wnrr v wxrr < wx): 
coruftrtonisignaKreadentry); 
con<titf<mfqueue(writeentry) a 

wn - wx a rn - rx a (rr - rn v wnrr - wxrr>. 
corutitomisignaKwriteentry); 
end; 
end writejenter; 

writejexit = procedure, 
wx := wx ♦ 1; 
choose 

con<tiriontqueue(readentry) a 

wn - wx a (wrrr ■ wnrr v wxrr < wx): 
conttitionfsignaKreadentry); 
con<toumiqueue(writeentry) a 

wn » wx a rn = rx a (it - rn v wnrr - wxrr): 
corutotonfsignaKwriteentry); 
end; 
end writejexit; 
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read j-equest - procedure; 
rr :- rr ♦ I; 
wrrr :- wr; 

wnrr :- wn; ; 

wxrr :- wx; -, 

choose •. - ..,= -• 

con<frtfonSqueue(readentry) a 

wn - wx a (wrrr - wnrr v wxrr < wx): k: 
conrftrionlsignaKreadentry); 
con<titf0niqueue(writeentry) A 

wn - wx a rn-rx Anbfnm .;-*? Purr— wxrr): 
ceo rf tf / o w |» ig naKwriteentry){ • 

end read_request; . 5 

read_enter - procedure-, 

if wn * wx v (wrrr * wnrr A wxrr i wx) 

rA«n conrfifionfwaiKreadentry); tiui; 
rn :■ rn ♦ I; 
choose 

con<&/ipnfqueue(readentry) a 

wn - wx a (wrrr « war* v ^wjarr < wx): 
condttfontsignaKreadentry); 
con<tittontqueue(writeentry) A 

wn - wx a rn - rx a 4$t m ra v wnrr » wxrr): 
<»ikfctf<ratMgnaKwriteentry)s 
end; 
end read jenter; * ■'-.-;; 

readjexit - procedure-, 
rx :» rx ♦ 1; 
choose 

con<ftfionSqueue(readentry) a 

wn » wx a (wrrr - wnrr v wx«<wx): 
condtftonSsignaKreadentry); 
conrfif ton|queue(writeentry) a 

wn « wx a rn - rx a (rr •**» v wnrr » wxrr): 
crarfttomlsignaKwritemtry); 
end; 
end readjexit; -.: 

wr, wn, wx, rr, rn, rx :- 0, Q,ft ft 0, ft 
wrrr, wnrr, wxrr, :- 0, 0, 0; 
end apdb; 



- 183 - 

specification dh specifies this mutual exclusion, and the second specifies the scheduling 
policy desired: 

«a n / n f r =>a n wrt - r ) D (* m ***=*z n ~«* r )) a 

«a i (x2) rw ^ ,t => a k (xir* =» a i (x2r rt * r ) a 

(a^y*^ -1 =* a k (xl)" xit =» aj(x3r rt,r ) a 

(xl < x2 < x3 v xl > x2 > x3) D 

( ai (x2) ,Btaf =» aj<x3r ,w )). 

The analysis of the first conjunct has been carried out already in Section 6.3, where the 

same property was specified for operation "write" as part of the "readers-writers" property. 

Here we will consider the scheduling property conjunct dh<j. 

First, the argument constraint predicate (xl < x2 < x3 v xl > x2 > x3) must be 
incorporated into the conjunct. The predicate already appears in the hypothesis of an 
implication. It can be incorporated by parameterizing it and then qualifying the 
appropriate procedure activations. The parameterized form of the predicate is 

(xl - u) A (x2 - t) A (u < t < x3 v u > t > x3). 
This means that activation a k (xl) must be qualified with the predicate (xl - u), activation 
a|(x2) with the predicate (x2 - t), and activation aj(x3) with the predicate (u < t < x3 v u > 
t > x3). The transformed specification then becomes: 
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<[a,(x2) i <x2 - t>r ?qMrtt =-» &i k (xt) i (xi - usr* **i»^c2> * <«2 - or B,-r > a 

<Dij(x3) | (u < t < x3 v u > t > x3)r , ^ rt =» b k (xl) | (xl - u)]™* 

=* lkjCx3^ Kb < t < x3 vu > t > j&W**"} 

O ([a;(x2) | (x2 - Or*" =» taj(x3) | (u < t < x3 v u > t > x3)r*"). 

Now that the argument constraint information has been hkorporated into the conjunct 
by means of qualification, the analysis can proceed normally. There are five events 
mentioned in the conjunct: 

Evexp^rtg) - fcjfcS) Hx2 *t)7^H*, . {^(xty-M *0F^H K^ ' <xl * u)r *' 
£aj(x3) | (u < t < x3 v ir». t ».x9ff aq ^.-'fcj{ft$tfe <i -x «3 * »* t > x3)r ntar }. 
There are 30 possible orderings among thea* five eqe«s/i;«ath»r than lot a#30 of them, 
only the two invalid ones are given here 

(1) [ ai (x2) | (x2 - or^" - => Eaj(x3) I (u < t < x3 v u > t > xl)!**"" =* 

ta k (xl) | (xl - u)]" H =» faj(x3) | (u < t < x3 v u > t > x3)T*" «* 

[8^x2) | (x2 - or**. 

(2) [ aj (x3) | (u < t < x3 v u > t > x3)r quMt =» U 4 (x2) | <x2 - tiT"****! => 

[a k (xl) | (xl - u)r a =* taj(x3) | (u < t < x3 v u > t > x3)r** r => 
[ ai (x2) | (x2 - t)T*". 
The offending event in each is taj(x3) | (u k t < x3 v u > t > x3)] w,,w . This means that a 
condition must be derived for gate [a(x) |(u<t<xvu>t> x)]* rt * f . Since the state 
characterization is the same at the point of the offending event in both orderings, this 
characterization becomes the term Dj: 
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3 (i, j. kMcountffate) { <x - *W n }± k a 

co»nt<[a(x> | (u < t < x v u> t > ■*&***)>* | a co*Htf<k(x) | (r • tH***"^ £ t a 

couitt((ia(x) Km < t -t x v u >t * W**) «f A emHitgsfeH (x -- ®P**)) < i> 



The term D v , being the disjunction of 23 characterizations, is quite complicated. 
However, when the expression <D V a (-* Dj» is constructed, the formula can be simplified 
considerably. The result of the simplification is to arrive at the following preliminary 
condition: 

V i (count([a(x) | (x - or*"*) < i v count([a(x) | (x - 07^)) > i). 
This is equivalent to the even simpler 

count(Wx) | (a - ^W^- coanMuWx) | (k * Or*). 
This condition is found to satisfy a» the valid orderings, and therefore is correct as it 
stands.' 

The overall solution specification for specification dh consists of the following gate 
conditions: ; a 

For gate a* ntor : counttV^) -«wrt(^*) 
For gate Wx)l<u < t <x v «> t*^?^: 

countflato | <x * i}!**^ - eottntOa(x) t (x • t)] M,tor ) 
where u is the parameter of theactivatkm corresponding to 
the most recent a -1 * event ; '. > 

A monitor must now be constructed to implement this solution specification. 
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The monitor must contain three procedure* a .request. a_enter, and a_exit, to 
correspond to the three event ctoates. Since the** at* qualified gates in the solution 
specification, each of the monitor procedures must t»ke the same parameter x as operation a. 
There must be variables an and ax to represent cousit(a" rt " r ) and count<a MH ), respectively. 
In addition, there must be a local variable u of type trackjrto, the same type as parameter t, 
representing the value of the parameter of the most recent call on procedure a_exit. This 
variable should be initialized to an appropriate value, such as the minimum possible track 
number. 

In order to implement the parameterized counts, thee* mutt be two objects atreq and 
atent of type countsftraekjwi to hold *be value* of c*unttfa<xM <x - tW**" 8 ') and 
count([a<x) | (x - $?*•*} for all values of ;.«. Procedure a_request tocrememj a count in 
atreq, and procedure ajenter increments a count in atent Each of these objects musk be 
created in the initialization code for the monitor. 

The qualifying predicate on the p"^ gate 

(u <t <x v *>t >X)f: *^ 

is a non-functional relation. The entry conditions ma* be implemented by an object aentry 
of type conditidnsftraekjnol that holds «ne ^^ eoiiditicir^ for all ttelevant values of x. A 
condition for a fiven value of x is added to aentrf byan !add?" operation at the start of 
procedure a_enter. The predicate associated with the condition for value t is given by 

an - ax; a cnts*get(a<teqi l) *^ls%e«Ne*jel)^ • 
combining the predicates associated with the unqualified and qualified gates. It is also 
necessary to have an object "tracks" of type set[track_no] to maintain the set of relevant 
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track numbers. Elements are added to track by "insert" operations within procedures 
a_request and a_enter. The resulting monitor appears in Figure 6.6. 
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Figure >%&. Monitor for disk fcead sdteduter 

dh - monitor; ; ! 

an, ax: integer, 

u: track_no; 

atreq, a tent: count$[track_no]; 

aentry: conditions[track_no]; 

tracks :« set[track_no]; 

a_request - procedureix :track_no); 
counts[track_no]f incr(atreq, x); 
set[track_no)iinsert(tracks, x>, 
/or z:track_no in conditions[track_no]tdomain(aentry) do 

if conrfrtioniqueue(condUions[track_no)iget(aentry, z» then 
6k:boolean :- <ri«; 

for t:track_no in set[track_no]tetements(track$) do 
if (u < t < z v u > t > z) A 

(an * ax v counts[track_no)tget(atreq, t) * 
counts[track_no)fget(atent, t)) 
then ok :» false; end; 
end; 

if ok then c<md«<<m$signaKconditions[track_no)tget<aentry, z)>, end; 
end; 
end; . 
end a ^request; 

a_enter - procedure{\-XrzcY.jno)\ 

conditions[track_noHadd(pentry. x>, 

for t:track_no in set[track_no]telements(tracks) do 

if conrf«iontqueue(conditions[track_no]lget<aentry, x» a 

(an * ax v counts[traek_no]iget{atreq, t) * countsftrack_no]*get(atent ( t» 
then conrf«ionjwait(condition$(track_no]lget(cond$, v)X *nd; 
end; 

an :» an ♦ 1; 

counts[track_no]Sincr(atent, x); 
set[track_no]tinsert(tracks, x); 
for z:track_jio in conditionsttrack_no]ldomain(aentry) do 

if conrftriontqueue(conditions[track_nb]|get(aentry, z» then 
ok.boolean :- true; 

for t:track_no in set[track_no]telements(tracks) do 
if (u < t < z v u > t > z) a 

(an * ax v counts[track_noSget(atreq, t) * 
counts[track_no)tget(atent, t» 
then ok -."false; end; 
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end; 

if ok then conrf«ion$signal(conditions[trackjio]*get(aentry, z)); end; 

end; 
end; 
end a_enter; 

a_exit - procedure(x\racY.jno); 
ax := ax ♦ 1; 
u := x; 
for z:track_no in conditions[track_no]$domain(aentry) do 

if conrfiri<mtqueue(conditions[t:rack_jio]Sget(aentry, z)) then 
okiboolean := true; 

for t:track_no in setftrack jio]telements(tracks) do 
if (u < t < z v u > t > z) a 

(an * ax v counts[track_no]$get(atreq, t) * 
counts[track_no]fget(atent, t)) 
then ok := false; end; 
end; 
if ok then conrf«M>nlsignaKcondition$[trackjio]lget(aentry, z)); end; 

end; 
end; 
end a_exit; 

an, ax := 0, 0; 
u := track_noSmin(); 
atreq := counts[track_no]tcreate(); 
atent := counts[track_no]lcreate(>, 
aentry := conditions[track_no]$createO; 
tracks :«= setftrack _no]fcreate(); 
end dh; 
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Chapter 7 
Detecting Erroneous Specifications 

7.1 Introduction 

The flexibility of the problem specification language makes it possible to specify a 
wide variety of synchronization constraints. Unfortunately, this flexibility also permits 
erroneous specifications to be constructed. Certain kinds of errors in specifications can be 
detected in attempting to derive equivalent solution specifications. As noted in Chapter 4, if 
a specification constrains when in a history, say, a request event can occur, this results in an 
invalid ordering being found in the derivation algorithm for which the offending event is 
of type request. Since this is erroneous, in that the underlying model requires events other 
than enter events to be unconditional, the derivation algorithm detects this error and fails 
to construct an equivalent solution specification. 

There are other kinds of erroneous specifications, however, for which equivalent 
solution specifications can be derived. These specifications are compatible with the 
underlying model, but the synchronization constraints they specify display certain forms of 
undesirable behavior. Two such forms of behavior are the potential for deadlock and 
starvation. Deadlock results from a situation being overconstrained, so that each of a set of 
waiting processes is prevented from proceeding by the presence of all the rest. Starvation 
means that the constraint that is specified may be too rigid, in that certain processes are 
prevented from proceeding indefinitely. 
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A problem specification that manifests ©we 'itf-thefe forms of behavior results in the 
derivation of a soluticMv specification that (toes Wiev»w,HDv^vier^ the form of the solution 
specification makes the analysis required to detect these erroneous behaviors much more 
tractable than for the problem specification itself. This chapter presents algorithms for 
performing such analysis. They can be used, once a solution specification has been i derived 
from a problem specification, as a check on the soundness of the original specification. 

By the argument in Chapter 4 justifying the derivation algorithm, the set of histories 
allowed by a derived solution specification is exactly equal to the set allowed by the original 
problem specification. This means -that V potential fbf deadlock or starvation cannot be 
introduced into the solution specification Of the derivation itself, since if this were possible, 
then there would have to be one or more histories valid with respect to the probfem 
specification but nor to the solution specification. Rather, since the solution specification 
corresponds exactly to the problem specification in hittorf*h«^lc^ for 

deadlock or starvation in the problem specification is mirrored in the solution specification. 

For example, a potential for deadlock would be reflected by the existence in a valid 
history of request events for which the cbh^fio^ir^^^ events could never satisfy the 
specification; Assume the existence of sucha hirtory <?fli W validity with respect to a 
solution specification. Then this same history must bM Vahd wfth^t*%ect Mr the problem 
specification, and the entet events must fail to satisfy the problem specification, as well. Of 
course, the reverse is similarly true Thus the solution specification must contain exactly the 
same potential for deadlock as the problem specification. In a sftnifar way. starvation 
implies that there are valid histories in which the request and enter events for a particular 
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operation activation are separated by an arbitmy nuraber of other request-enter event 
pairs. For a problem specification and a solution specifKation that are valid with respect to 
exactly the same set of histories, starvation w .one implies starvation in the other. 

Since the solution specification is state-oriented, it is a convenient form on which to 
perform the analysis for these properties. The solution specification can be used to 
determine under what conditions, if any, deadlock and starvation are possible. Such a 
possibility, though, arises due to the original problem specification, and it is there that a 
correction must be made. 

7.2 Deadlock detection 

In a survey paper ([Ho(72])>on the subject, 4#o<«oct is defined as "the situation in 
which one or more processes in a system are blocked forrver because erf i^qi^rements that 
can never be satisfied." In the context of this thesis*., deajiMockr arises when a problem 
specification overconstrains the order of events in certain situations so as to prevent any of 
a group of requested accesses from ever occurring. The entry conditions in the derived 
solution specification form a basis for characterizing possible deadlock situations in terms of 
the synchronization state of the object If deadlock is impossible, then each such 
characterization can be proved to lead to a contradiction. 

The problem of deadlock detection has been studied f*jr|y extensively, particularly for 
operating systems (eg. [Hav68], [Hab69]) and database systems ([Cha74]). The bulk of this 
work has used a common scenario for deadlock: Each process in a collection of concurrently 
executing processes holds exclusive access to one or more scarce resources, and is blocked 
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because of a request for resources held by other processes m the collection. The scarce 
resources are commonly viewed as devices in the case of operating systems, arid locks in 
database systems. Unfortunately, shared abstract data objects are not really similar to 
peripheral devices, which are serially reusable and must be "owned" by one process at a 
time. Nor is the database paradigm of setting and releasing locks on parts of the database 
very applicable to most situations involving data abstractions. Blocking of processes 
competing for access to an abstract data object more often results from calls on particular 
operations of the abstraction, rather than the subcomponents of the data object they access. 

Closer to the mark, from this point of view, is the work by Holt ([H0I7II [Rob75]). 
Using a Petri net-based model, Holt views a system as a set of states with transitions 
between them. With this approach, a process is Tbtocked* in a state when there is no 
transition it can make to another state, deadlock resuk* from a process being blocked in all 
reachable states of the system. The approach to be described in this section is similar. 

The solution specification into which the specification is transformed is a convenient 
form on which to perform deadlock analysis. The control points at which processes can be 
blocked are the enter gates, and the conditions the processes are awaiting to become 
unblocked are the corresponding entry conditions. A deadlock corresponds to one or more 
processes waiting at each of one or more gates, on conditions that can never become true. 
(It is assumed throughout that all operation activations terminate, so that processes can 
deadlock only via the synchronization code itself.) 
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For example, consider a data abstraction with two operations p and q. Suppose that 
in deriving the solution specification from the problem specification, it is discovered that a 
condition for passing through the p* n,,r gate is 

county*" * 8 ') - count(q'" Ur ). 
Now suppose also that a condition for the <\ mi ' r gate is 

count(p r " < ' • 8, ) - count(p' ntaf ). 
Obviously then, whenever there is a process waiting at each of the two gates p' n ' r and 
q en, ' r , these two processes are deadlocked. Each prevents the other from proceeding and 
thereby enabling the condition that it itself is awaiting. This means that the original 
problem specification is in error, in that the constraint it expresses prevents either activation 
in the given situation from ever proceeding. 

In the general case, a necessary but not sufficient condition for a collection of processes 
to deadlock over access to a shared data object is for each of these processes to be waiting at 
an enter gate for a condition to be satisfied. Whether or not this situation is a potential 
deadlock depends on whether the conditions on which the processes are waiting can be 
enabled by subsequent events associated with the shared object caused by other active 
processes. The idea behind the deadlock analysis technique to be described here is to 
characterize the synchronization state of the object at a potential deadlock point, a point at 
which processes are waiting at enter gates. This characterization then contains sufficient 
information for determining whether the entry conditions can be enabled by other active 
processes, or whether the waiting processes themselves prevent the conditions from ever 
becoming satisfied, in which case the situation represents a deadlock. 
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Each potential deadlock situation is distinguished by the subset of enter gates in the 
system at which one or more processes are waiting. The terminology used here is that an 
operation is blocked if there are processes waiting at the associated enter gate to execute it 
If there are n operations defined on an abstract data type, then there are (2 n - 1) potential 
deadlock situations, since any subset of the operations may be blocked, except the empty 
subset. An empty set of blocked operations could not, of course, represent a deadlock 
situation. 

A complication arises from the use of qualified gates in solution specifications. When 
there are two or more enter gate* for a particular operation, with a different qualifying 
predicate on each, the easiest point of view to take is that they behave like gates controlling 
completely different operations. In the context of deadlock analysts, it is simplest to consider 
two qualifications of an operation p, lp(v) | Qj(v)3 and tj)(v) } Qj>(v}3, as if they were 
separate operations pj and p<>, since each distinct qualification of p can independently be 
blocked, just as different operations can. The catch is that the qualifying predicates Qj and 
Q2 may not be independent, and if, for example, Qj D Qj>. then whenever [p(v> j Qj(v)] is 
blocked, [p(v) | (^(v)] must be as well. In general, however, it is not always possible to 
determine when one qualified class is a subset of another. Always treating different 
qualifications of an operation as separate operations is a conservative approach which is 
guaranteed hot to overlook any potential case of deadlock. Throughout this chapter, 
therefore, when reference is made to a data abstraction having n operations, the reader 
should understand that the intention is for different qualifications of an actual operation to 
be treated as separate operations. 
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It is straightforward to characterize a situation in which an operation is blocked. If 
C(p) is the condition for gate p' nUr , then the condition of operation p being blocked is 
expressed by the formula B(p): 

(-C(p)) a count(p requ " 81 ) > count(p" nUr ) a count(p" n, " r ) - count(p #xit ). 
That is, when p is blocked, there are no active executions of p, but one or more activations 
have been requested and are waiting because the entry condition C(p) is not satisfied. 

Assume that the potential deadlock situations are numbered 1, 2 (2 n - 1). and let Wj 

be the set of blocked operations in situation i. Formula Uj will denote the characterization 
of the synchronization state of an object in situation i, by expressing the fact that all 
operations in Wj are blocked. 

Uj - A (B(p) | p € Wj). 
If Uj is equivalent to FALSE, then there is a contradiction in the information in the 
formula. This means that the potential deadlock situation is impossible, and that a 
condition on which an activation of one of the blocked operations is waiting must be 
satisfied. If Uj is not equivalent to FALSE, then it represents a characterization of the 
circumstances under which the situation can occur. 

For a potential deadlock situation that is possible, the formula Uj can be used to 
determine whether or not the situation in fact represents an actual deadlock. This 
determination can be made by checking whether any of the conditions on which blocked 
operations are waiting involve operations that are not blocked in the given situation. If 
not, then the conditions can never become satisfied, and the situation in fact does represent 
a deadlock. If one or more conditions involve non-blocked operations, however, then there 
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is not a deadlock, since a subsequent event involving one of these operations can "unblock" 
the situation and enable one of the waiting processes. At the very worst, such an event may 
change the situation to a different potential deadlock situation/ to be analyzed separately. 
Therefore, it is sufficient to Arid a single non-blocked operation that is involved in the 
waiting conditions to disprove deadlock for a given situation. 

As an example of deadlock analysis, consider the solution specification for a writers' 
priority database given in Section 6.3. Since there ar* two operations, "read" and "write", 
there are three potential deadlock Htuatkms--procesies waiting only at the r*ad wl, * r gate, 
only at the write* flt ' r gaee, and at both gates. In the first situation, W(f) - { read ). The 
description of this situation Uj is given by the "blocked" condition On the "reacT operation, 
B(read): 

(count(write ,w * s, ) * cou»t(writ<f M * ?r ) v Oou«t(wriie w ^ ■*' eort»t(wriW , '' M )) a 
counfOead'*^') > amntOead*"**) a counKread^^) - «ouirt{read*" H ). 

The condition on which "read" activations are waiting involves events associated with 
the non-blocked operation "write". This is not an actual deadlock situation, since the "read" 
activations themselves are not causing the blocking. This does not necessarily mean that 
the processes blocked at the read*"** gate win" eventually proceed: Tftert imf exist histories 
in which these processes are blocked forever, i.e. they may face th* possibility of starvation 
(see the next section). What the analysis here shows isthat drcutnstances exist, Involving 
possible future events associated with operation "write", that make unblocking of these 
processes possible. Their being blocked need not be a permanent condition for all possible 
histories. 
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T he second situation is when only "write" is blocked, i.e. W<2) ■■- { write }. The 
description here is U£ * B( write): 

(count<read' n!v ) * cotlBt{read" d, ) v eo«*t(write* ,,pr ) * count(write , '"*» a 
count(write r,<,u,,t ) > count(write"^ A CMtiit(write'" Ur ) - ce4*^wrtte MM >, 
which can be simplified to 

coutit(read" ,to *) * cottntfread*™ 1 ) a 
count(write r * qurt ') > count(write , " tor ) A count(write" ltar ) - eoo»t<wrtte• K,, ). 
Since the blocking condition involves the nonHriocked operation "read", this is also not an 
actual deadlock. 

The third potential deadlock situation for the abstract object involves waiting readers 
and writers, so that W(3) - { read, write }. This situation is characterized by U 3 - (B(write) 
A B(read)): 

(counKread""*") * countfread*"*) v co^lllt(write^ ,to, ) * eount(write**' t )) a 

count(write r ^'* rt ) > count(write• ,,h, ) a count(write^**) - cott■t(write• , ' i, ) a 

(count(write r ^ w * t ) * counUwrite - "'*) v couBt(write* ,ta O * count(write* Kit )) a 

countCread^^XfcCOiitrtCmdf^A t»Uat(read* ,tar ) - cww^read""*). 

Here there is a contradiction, between the firrt distinctive clause on the one band, and the 

third and last conjunct* on the other. This reduces the fixroubx to FALSE, proving the 

situation to be impossible. Sinn this disposes of ail three potential deadlock situations, 

deadlock is proved to be impossible for this abstraction. 
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As a second example, consider the bounded buffer exarnpteanarfyied in Section 6.2. 

Once again, there are two operations, and therefore three potential deadlock situations for 

this abstraction. The first is when only operation ^B^^Woeked^ ib that W<^ - { rem }. 

This is described by the formula Uf - B&em)? 

(count(dep* xH ) < count(rem wrtw ) v count(rem #nta, > * co«tttfe«m<**)) A 
count(rem f • < ^• , ) > count<rem'^ K ) a- countOwn"**') - count(rem*" M ), 

which reduces slightly to: ; c 

! «01l|^dep•^) S :oawlt(r«m» n, ^, a 
countO-em'"*" 8 ') > count(rem" B,,r ) a count<rem• ,,to, ) - count(rem M *). 

Since the formula is not equivalent to FALSE, the situation is possible. However, the 

condition on which "rem" activations are waiting, namely 

count(dep" ,H ) < count(rem• ,,to, ), 

involves operation "dep" that is not blocked in the situation. This means that the condition 

need not be prevented from ever being satisfied, and so this does not represent an actual 

deadlock. 

The second situation is when. «uyi"de|r is btockad, and "VW - { Sep }. The 
characterizatioa of this sttuatran is given by U^ - B(dep); 

■ : (eoufltCwca?^) £ count<dpp^ ,r ) - N v «ount(*tp»"^ * eount(d*p , * rt » a^ 
coidit<dep r f?^^4W»ai<d«p M ^XrA: ooUB^dep^') - eoutrt^dep"* 1 ), 
which simplifies to: ? "■'<■{■-> 
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count(rem exH ) < count(dep wrt " r ) - N a 

cou!l<(dep re «' u • s, ) > count(de P • nU, ) A count(dep ,ntar ) - count(dep* xit ). 

This formula also is satisfiable, but once again, the waiting condition involves a 

non-blocked operation, in this case "rem". This means that the potential for deadlock is 

« 

averted. 

The third inactive situation involves both "dep" and "rem" being blocked. W 3 - { 
dep, rem }, and U 3 = (B(rem) a B(dep)): 

(count(dep' xi *) < count(rem #nUr ) v count(rem" ntw ') * count(rem' xi, » a 

count(rem reqo,s ') > count(rem ,Btor ) a count(rem' rt * r ) - count(rem* xi! ) a 

(count(rem ,xit ) < count(dep ,ntar ) - N v count(dep' ntar ) * count(dep* xit )) a 

counUdep'-^ 8 ') > count(dep w,,w ) a count(dep ,Btor ) - count(dep" xit ). 

For any value of N > 1, this formula reduces to FALSE, since it implies that 

count(dep Bntar ) - count(dep ,xil ) < count(rem• n, • , ) - 

count(rem* xi, > < count(dep• ,,, • , ) - N. 

Therefore, the situation is impossible. In conjunction with the previous analysis of the 

other two situations, this means that no deadlock is possible for the "buffer" type. 

7.3 Starvation detection 

A related problem to deadlock is the notion of starvation. Starvation means that while 
a process that is waiting to access an object is not necessarily blocked permanently, a pattern 
of accesses exists that prevents the process indefinitely from proceeding. The opposite of 
starvation is fairness, which indicates that every process is guaranteed eventually to have its 
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request for access fulfilled. A method analogous to that used for deadlocks can indicate a 
large class of possible starvation situations, specifically those that are independent of 
parameter values. 

Unfortunately, not all starvation possibilities can be easily detected. For example, the 
disk head scheduler example of Example 14 in Section 2.7 is starvation-free, but the 
simplified version analyzed in Section 6.5 is not. The fairness of the former specification 
depends upon (1) the range of track numbers being bounded, and (2) the set of track 
numbers being well-ordered. The proof that these are sufficient conditions for fairness 
involves non-trivial properties of well-ordered sets. In general, properties related to 
activation parameters, specifically to predicates qualifying gates in the solution specification, 
involve analysis that is too complex for the relatively simple starvation detection method 
outlined here. Such properties do not cause similar problems for deadlock analysis, since 
there the issue is simply whether any activations of an operation can proceed under any 
circumstances. Starvation analysis must determine whether an arbitrary activation 
eventually can proceed under all circumstances. This means that interactions among 
different activations of an operation become more important. For those starvation 
possibilities that can be detected by the method to be presented, the same approach to 
qualified gates is taken as for deadlocks. Different qualifications of an operation are treated 
as distinct operations, and each is analyzed independently for starvation. 
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The motivation for the starvation analysis presented below is as follows: For a process 
to starve, it must be kept waiting .indefinitely at the enter gate for some operation. Since 
the synchronization mechanism itself is fair in scheduling activations whose entry conditions 
are satisfied, this can only happen if the condition on which the process is waiting is never 
allowed to be satisfied, due to the presence of other operation activations. (As before, all 
operation activations are assumed to terminate.) Therefore, it must be possible for processes 
executing other operations of the data abstraction to overtake the waiting process. 
"Overtaking" refers to the fact that even though the given process is waiting at an enter 
gate, processes making other activations whose request events occur later proceed through 
their respective enter gates ahead of it. 

If operation q cannot overtake operation p, then whenever an activation of p is 
blocked, eventually all activations of q that were requested prior to the request for p must be 
completed. Under circumstances in which the activation of p starves, therefore, no 
subsequent activation of q can proceed either. Thus the first step in the starvation analysis 
for a particular operation is to determine which other operations of the abstract data type 
can and cannot overtake it. The characterization of a starvation situation then states that 
the given operation is blocked, and that no "non-overtaking" operations are currently active. 
This characterization reduces to FALSE if there is a contradiction in the situation, meaning 
that starvation is impossible. 
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Formaiiy, the method of analysis for each operation p is the following: As before, B(p) 
denotes that p is blocked: 

(- C<p)) A count(p r#qMrtt ) > count^^ A count^**") - count^X 
For all q * p, construct the formula T(q, p) given by 

B(p) a C<q) A (count(q TW,M * t ) > couWq**")). 
This formula indicates under what circumstances a process executing operation q can 
overtake the process blocked at gate p""*", i.e. when there are requested activations of q and 
the entry condition for q is satisfied. It T(q, p) is other than false, then it is possible for an 
activation of q to overtake the waiting activation of p. Therefore nothing can be assumed 
about operation q in a starvation situation for p. If T(q, p) reduces to FALSE, however, 
then this overuking cannot occur, and a process waiting at p£? wMI cause a process 
subsequently arriving at q - "'*' to be blocked af wejl,. This iwranMhai no activations of q 
can be active in a starvation situation for p. The starvat^ 
conjoinuig to B(p) the formula 

couut^^-coumiq"^ 
for each q for which T(% pj is FALSE, That is, 

. S<p) - A (count<q" ,,,r ) - cou«t(q" xrt ) 1 T(q, p) - FALSE) A B(p). 
This indicates that since q cannot overtake p, eventually Jio executions of q will be active. 
If S(p) is FALSE, then starvation of processes attempting to execute p is impossible, in that 
the hypothesized starvation situation for p contains a contradiction. Otherwise, S(p) 
characterizes a possible starvation situation. 
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Again, consider the writers' priority database as an example. The condition for gate 

write' n, " r is 

(count(read' nt,r ) = count<read ,xH ) a count(write ,nUr ) - count(write" <rt )), 
so the blocked condition for operation "write" is B(write): 

(count(read en, • , ) * count(read' xi ') v count(write• n, • , ) * count(write' x,t )) a 
count(write requ * s< ) > count(write ,nt-r ) a count(write wtar ) - count(write""'). 
The condition C(read) is given by 

count(write r • <,u • s, ) - count(write' nt,r ) a count(write w, * r ) - count(write' x,t ). 
This makes the overtaking condition T(read, write): 

(count(read" n,,r ) * count(read" xH ) v count(write ,n,w ) * count(write' x,t )) a 

count(write r " qu8S ') > count<write* ntar ) a count(write* I,Ur ) - count(write"" , > a 

count(write f • qu • 8, ) - count(write entaf ) a count(write wtor ) - coullt(write• , " , ) a 

count(read" qM * ,t ) > count(read , " tor ). 

Since the second and fourth clauses contradict each other, the formula reduces to FALSE. 

This means that the clause 

count(read ,ntar ) - countO-cad'"") 

is conjoined to B(write) to form S(write), the starvation condition for operation "write": 

(count(read ,ntaf ) * count(read wi ') v count(write• lrt • , ) * countfwrite"" 1 )) a 

count(write ,,,,u,8t ) > count(write w,w ) a count(write Mtaf ) - countfwrite™" 1 ) a 

count(read*" tor ) - counKread""*). 

This formula in turn is FALSE, since the last two conjuncts together contradict the first 

disjunctive clause. Starvation of writers is therefore impossible. 
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If a simitar analysis is performed for the "read" operation, B(read) is constructed as: 

(coullt(write r • , ^ w, ) * count(write , " tar ) v count<write* M * r ) * count(write• ,, ' , )) A 

» 

. counKread*^ -1 ) > eounUread* 11 ^ a c^nifftid^^-icoMnt^read* 11 ^. 
The condition of "write" overtaking "read", TCwrite. readX fc then formed: 

(count<write r **"* , > * couiit(write*"**) V cotant(wrtte* , '*>* counUwi^***^ a 

count(read f * ,t * ,t y > count<fe«*• ,lll *) A 'cte«$totf* , *)F* co««t(read^ , ) a 

count(read• n, • r >-count<read•" i, ) a count(write*" tar y • ifie«rtfwH« M,, > a 

coun^write* - *) > co^nt<#rlfe f *' , ). 

This formula is not identically FALSE, however, so that operation "write" can indeed 

overtake "read". This means that the starvation condition Spread} is simply equal to the 

blocked condition B<readK Since S<r«rd) is not FAlLSf, starvation <Sf read«r* is indeed a 

possibility, as expected, and can take pbee under the cireumsSarttes given byt 

<count(write fW,uM ') * cou«t(wrfte , *"y v ^unl?v#ite*^ * count<write , * i ')) a 
co^ri^i^d f ^ ,w ^>ce«iiKi*id**^ A ^c^ii«(*ea<f* tor ) - ©wwitfread***). 
That is, as long as there are activations of "write" that are either requested and pending, or 
active, then requested activations of "read' may starve. • 
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Chapter 8 
Summary and Evaluation 

8.1 Summary of the thesis 

This thesis has explored one approach to the problem of, specifying synchronization 
properties and synthesizing source language code to implement tbm The approach Uken 
has depended on a basic model of abstract data objects and synchronization. wlijch was 
described in Chapter 2. The principal features of this model ajrejL 

(1) Every data object is strongly typed, and any access of the object must be via a 
basic operation of the type of the object 

(2) Certain points in time, called matt* are distinguished in a computation 
history involving accesses of a ghvm „,|toua ,;$*£$>.. -}n J*Mtte u ;k r . tbew are 
three types of events: request event*, whfch denote processes making known 
their wish to gain access to the object; enter . t ven|s,.. which denote successfully 
gaining access; and exit events, which denote relinquishing access. 

(3) The temporal precedence relation among events associated with a given data 
object is a total ordering relation. 

(4) The function of synchronization is to constrain in certain ways the time 
ordering relation on a data object, in particular the occurrence of enter events 
within the total ordering. This function is orthogonal to the meaning of the 
operations by which processes access the object, and therefore can and should 
be implemented separately from those operations. 
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(5) Individual synchronization constraints ekist for each object in the system. 
Furthermore, a ^ncbroneaUon constrain^ if a^c»ased with a data type, and 
applies independently to each object of that type. 

Using this model as a basis, a specification language was described in Chapter 2 for 
expressing synthronmTion properties of abstract data types A notation was devised for 
denoting events, and the* mfix^lymtibl "^^ttiflteM fw the^ftme ordering relation. 
Spetmcatidm express coristhimts' c*i th» rebttt WpWcate '«affe^'1ioM^ : l^oitln^' 
the time ordering between universally quantified event -expressions. The quantification 
causes the constraint to apply to att eveitts of a given cfcsi in a history. By explicitly stating 
the arguments to procedure invocations involved in i a specification and using predicates to 
constrain these arguments, a constraint ion the ^ rebtioTi can be made to selectively apply 
to a subclass of events The fc^ of 

defining the validity of histories with respect to a divert specification. A number of 
examples of the use i>f the language to express synchroniiation' Constraints appeared at the 
end of Chapter 2. 

To synthesize source language code implementing the specifications, it was found to be 
desirable to use an intermediate form. This form, called the solution specification, was 
described in Chapter 3. It is an abstract representation of the solution to a specification that 
is procedural in nature but independent of the particular construct used for implementation. 
A solution specification consists of a collection of gates, which are abstract implementations 
of event classes. Synchronization constraints are implemented by attaching conditions on 
the synchronization state to gates for enter event classes. Processes are only allowed to pass 
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th rough gates when the corresponding conditions are satisfied. The semantics of a solution 
specification, as of the problem specification, were defined in terms of the validity of 
histories. Translating a solution specification into an implementation using a 
synchronization construct such as a monitor is quite straightforward, as explained in 
Chapter 5. Therefore, the difficulty in synthesis is deriving the solution specification from 
the problem specification. 

This derivation was the subject of Chapter 4. Besides simply identifying which gates 
are needed for a specification, this consists of constructing appropriate conditions on the 
synchronization state to associate with enter gates in order to implement the specified 
constraint. The construction of these conditions is accomplished by an algorithm that can 
be broken into several phases. First, constraints on the arguments to activations are 
incorporated into the rest of the specification by a technique called "qualification". Once 
this has been done, all possible orderings of relevant events are formed, and each ordering 
is identified as either valid or invalid with respect to the specification. The synchronization 
state at particular events in both valid and invalid orderings is characterized, and these 
characterizations are combined to form a preliminary condition. This condition is tested 
among the valid orderings; it either succeeds in satisfying them all and is therefore correct, 
or else it fails in one or more cases, and must be weakened by disjoining to it one or more 
other terms. These weakening terms are derived in much the same way as the preliminary 
condition, except that a smaller class of orderings is used, and the characterizations involve 
synchronization states saved at previous points in the orderings. 
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Chapter 6 presented several examples of ! commonly addressed synchronization 
problems, which are specified and then synthesized by the approach described These 
examples certainty db not constitute a complete te«c^ an approach, but they db represent a 
fairly broad range ofWkln^bf spc*nx*izaiW^ interest. 

The topic of Chapter 7 was' the- analysis of a synchronization constraint for possible 
deadlock and starvation. The solution specification is a convenient form on which to 
perform this analysis. Algorithms were presented that for any given specification can 
disprove the possibility of certain finds of deadlock or starvation, or derive the conditions 
under which they can take place. 

8.2 The specification language 

.'■■'■:-..- .■'■ ■" ■ ■-■ "i •**'"'; ' 

There are a number of ways of evaluating the specification language described in 
Chapter 2. The example specifications in Section 2.7 attest to its power to express a wide 
range of synchronization properties. The derivation method discussed in Chapter 4 and 
further illustrated by the examples of Chapter 6 demonstrates its suitability as an input 
language for the synthesis algorithm. Two other related criteria are especially important, 
though subjective in nature the constrnctabilitj of the language, how easy is it to write 
specifications; and its comprehensibility, how easy is it to understand specifications. 

Within, the framework of the model of synchronization upon which the language is 
based, the language itself Is quite «6h>enieM'^'"writin^'sy^t^zation specifications. 
Since all of the standard logical operators of predicate calculus can be used, and formulas of 
arbitrary complexity constructed, any constraint on time ordering can be expressed. These 
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specifications are relatively easy to write and to understand, since each logical operator has 
a natural interpretation. The extensibility of the language permits a complex specification 
involving many constraints to be expressed as a conjunction of individual clauses, each one 
specifying a single constraint. This feature, illustrated by the different versions of the 
readers-writers problem considered in Chapter 6, enhances both constructability and 
comprehensibility. 

There may exist grounds for criticizing the language based on disagreements with the 
underlying model. For example, consider the choice of which points in time to be 
designated as events. Each of the three event types request, enter, and exit has a uniform 
meaning, and each is necessary for expressing a wide class of synchronization properties. 
Properties concerning exclusion of operations involve enter and exit events, and scheduling 
properties use request and enter events. 

Disagreement may exist, however, over whether these three types constitute a sufficient 
set. In particular, assume that some operation p may be blocked from proceeding, not 
initially before the activation begins, but rather at some point in the middle of execution. 
That is, suppose p performs a certain amount of computation, then must wait for some 
synchronization condition to be satisfied, after which it completes execution with some 
further computation. There is no straightforward mechanism in the model (and therefore 
the language) for denoting this "intermediate" event Such a situation must be handled by 
splitting operation p into two subsidiary operations pi and p2, which when executed serially 
constitute the whole of operation p. The intermediate point within p is represented by the 
exit event for pi and request event for p2. The condition on which it may be blocked is an 
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entry condition for gate p?**". 

While this may not be considered an aesthetically satisfying solution to the problem, it 
can be justified. The event types request, enter, and exit were chosen in part because they 
possess a uniform interpretation independent of the meaning of the particular operation. If 
a new event type intermediate were employed, its meaning (the intermediate point at which 
the operation may pause) necessarily would be operation-dependent. Moreover, a single 
intermediate event type would not be sufficient for handling operations 'that' may be 
blocked at more than one intermediate pomt. For the sake of generality, trrenl it would be 
necessary to have an unbounded number of event types lntefinediate-1, intermediate-2, .. . 
Whatever such an approach might gain in constructablUty of the language would surely be 
lost in reduced comprehensibitity. The solution eft&en instead of sphtting the operation p 
into component segments pi, p2, etc. seems at least as satisfactory. 

There is another important aspect of the specification language used here. That is the 
ability to use synchronization specifications, afcmg with the bodies Of the operations, to 
prove properties Of the data abstractions. One kind of proof is of the-fserial) correctness of 
an operation, with the synchronisation specification used to show that alt possibly 
interfering operation activations are excluded 'Wolm concurrent eiceeutidn. The 
synchronization specification also can be used to demonstrate that certain types of exception 
handling are unnecessary. An example is the bounded buffer fpedfication analyzed in 
Section 6.2, by which it can be shown that an activation of the "rem" operation never 
operates on an empty buffer. 
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One limitation of the specification language is an inability to refer to the state of the 
abstract data object to which a specification applies. There are good reasons for restricting 
the language in this way, as explained in Chapter 2. It is also true, at least theoretically, 
that any state information can be expressed injterms of events in the history. However, 
capturing state information via histories can make the specification of certain properties 
rather awkward. For example, the disk head scheduling specification of Example 14 in 
Section 2.7 could be simplified significantly if reference could be made to whether the disk 
head is moving up or down (at the point at which a certain event occurs). This limitation, 
however, does serve the purpose of maintaining a clean separation between the 
synchronization aspect of the data abstraction and the actual operations. 

8.3 The synthesis method 

The method for synthesizing synchronization code from specifications was presented in 
Chapters 4 and 5. The justification of the algorithm for deriving a solution specification, 
and a discussion of cases for which it fails, is presented at the end of Chapter 4. Failures of 
the algorithm really reflect an inability of the relatively rigid solution specification to 
capture certain synchronization properties of interest For example, the algorithm fails on 
the first-come-first-served specification because this property cannot be implemented using a 
separate queue for each operation of the abstraction. On the whole, though, and 
particularly with the use of qualified gates to capture parameter-related properties, the 
solution specification structure is able to express the solutions to almost all synchronization 
problems that can be specified in the problem specification language 
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The monitor implementation of the sokition specification is relatively straightforward 
in most cases. The exception to this is the handling Of pararneteriaed gates using the types 
coumsTT] and conditfonsfn The implemenutk* of parameterized enter gates in 
particular, especially where the ouaiifylitf pjedftate I* not a funttionar relation, becomes 
quite complicated. As noted in Chapter S, a certain amount of simplification would be 
possible if the user were to supply the range of values Wat each parameter could assume. 
This information could also be used to prevent the decrease in expressive power that results 
from having to make certain assumptions about the solution specification conditions in 
order to construct a correct implementation. 

Chapter 6 contains a small set of examples in which implementations are completely 
synthesized from problem specifications. In fact, a coruidertbly larger Vnimber of examples 
have been worked out, including all of the specifications presented as examples in Section 
2.7, with the exception of those explicitly cited in Chapter 4 as failures. The method 
appears to satisfactorily synthesize implementations for a wide class of specifications, except 
for those properties for which solution specifications cannot be obtained, as noted above. 

Two other measures of the synthesis method are tmportaffl to discuss here. The first 
of these, the pmtfeallty of the? synthesis algorithm, appears open to question. In the 
derivation of the solution specification, all possible ordermgs of the event expressions 
contained in the specificatkm must be comidensd, and since n events may have as many as 
n! order ings, the algorithm is necessarily exponential. Ri a>ss formal sense, the practicality 
is weakened by the coiripJefcin; of 'sente ^ 
requiring a logical simplification of formulas. Compensating somewhat is the fact that the 
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formulas involved are of a restricted form. Therefore, a small collection of special-case 
simplifications, such as those appearing in Figure 4.2, rather than the power of a 
general-purpose logical simplifier, would probably be sufficient for implementing a system 
based on the method proposed here. Also, the ability to analyze each conjunct of the 
specification separately helps reduce the overall complexity. 

Still, improvements in the algorithm are required to make it practical in, say, a 
compiler. The algorithm as it stands can be used manually by a person to implement a 
synchronization constraint expressed in the specification language, or to informally check a 
hand-coded implementation. Further work, as discussed at the end of this chapter, is 
needed to automate the algorithm. 

With respect to the other measure of evaluation, the efficiency of the synthesized 
source code, the method can be judged to be quite respectable. There are certain 
inefficiencies that necessarily result from the use of a relatively fixed structure. Two aspects 
of the fixed structure here are particularly restrictive. One is the use of separate condition 
variables for different enter gates, which prevents the queuing of processes waiting to 
execute different operations on a common queue. The other is the derivation of a single 
entry condition applicable both initially when a process first attempts an access and 
subsequently when testing whether to allow the deferred access. 
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As a result, the synthesized monitor for the "alternating priority database" example of 
Section 6.4 is awkward compared to the rather elegant monitor coded by hand to solve the 
same problem in [Hoa74]. Much of this awkwardness, however, is due to the simple-minded 
implementation of testing for possible signalling all condition variables at the end of each 
monitor procedure. As indicated in Chapter 5, optimization of the signalling statements by 
eliminating provably unsatisfiable options is often possible. 

On the whole, synthesized implementations approach hand-coded ones in terms of 
efficiency for a large class of problems. The fact that all synchronization code manipulates 
only integer-valued quantities, and that entry conditions always consist of linear equalities or 
inequalities of such quantities, keeps the implementations efficient. The efficiency can be 
enhanced if other obvious optimizations are applied to the results of the straightforward 
synthesis, such as using a single variable for a quantity of the form 

count(ecl) - count(ec2), 
rather than two separate variables for the two different counts. 

Where the efficiency of the synthesized code becomes unacceptable is in cases 
involving parameterized gates, such as the disk head scheduler of Section 6.5. In order to 
accommodate the structure of the solution specification, the parameterized types counts[T] 
and conditions[T] must be employed to implement what amount to entire arrays of counts 
and conditions. Here, the fixed structure of the synthesized implementations becomes a real 
barrier to an efficient implementation, since "good" implementations of such properties make 
use of special mechanisms such as priority queues. With the exception of parameter-related 
properties, though, the performance penalties paid for most specifications seem to be within 
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the limits of what can be reasonably expected from an automatic synthesis system. 

8.4 Comparison with path expressions 

As noted in the introductory chapter, the work on path expressions ([Cam74], [Hab75], 
[Flo76]) most nearly matches this thesis in terms of overall goals. In evaluating the thesis, 
then, it is instructive to compare it with the path expression work to see to what extent each 
meets these shared goals. In terras of this comparison, the path expression language is 
restricted to its original description in [Cam74l Later versions have added successively 
more features to the language, with questionable results. The original language simply 
contains the basic features that make path expressions analogous to regular expressions, 
namely the sequencing operator " ; ", the alternation operator " , ", and the repetition 
operators "{ ... }" and "path ... end". The analogy with regular expressions embodies the 
basic philosophy underlying path expressions. 

The approach both of this thesis and of path expressions is to constrain the ordering 
relation on accesses to some shared abstract data object Access of the abstract object is 
limited to a collection of basic operations associated with the type of the object, and so each 
language specifies a subset of possible object histories involving these operations to be 
vahd. For path expressions, activations of the operations are treated as units, while this 
thesis has denoted three particular points in time associated with each activation as events, 
and dealt with these events rather than the activation itself. 
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T he path expression : approach is to specify a global constraint for the complete 

sequence of accesses represented by the overall history. The specifications of this thesis^ on 

.^id^'-f^qns l.U- • sis* -~ *iir<-.i-:. .v. ■•.?.■•■*..'■ ■. >■ 

the other hand, represent local constraints for individual operation activations; because the 
activations involved frr a specif ieatton are ^ahtffied, the torotrtints apply individually to 
each activation in the history My intuition i» that tedH constraints are inherently simpler, 
both to construct and to cc^mpreherKi, and that people must translate global constraints fftto 
local ones to understand them. Thu is a subject rve judgement, however. 

The path expression language uses as basic notions the concepts of mutual exclusion, 
sequencing, and concurrent repetition. These are at a higher level than the more primitive 
temporal ordering relation =*. Use of such higher-level concepts facilitates the expression 
of properties that are based closely on them. For example, the readers-writers property, 
appearing as Example 3 in Section 2.7 in the form 

«write i * nW =* writej # " ,,r ) D (write^** =» writej"^')) a 
flwritef* ^r*Mf**f v '~<faify*****mteff*% 
can be specified by the path expression 

path { radlmfami. 
The gain in eomprehensi bjhty and construdabfHtyis obvious. 

a ' 

However, the same result can be achieved by using some sort of macro facility with the 
language of this thesis. For example, MUTEX(p, q) could be employed as a shorthand 
abbreviation for the mutual exclusion specification of Example 2 in Section 2.7: 

<p«* => q *<*") v ( qj «* => p .«f) t 

and the readers-writers property then could be expressed as 
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MUTEX(write, read) a MUTEX(write, write). 
Such a macro facility would also be useful in identifying specifications for which 
implementations have already been derived in the past, thus eliminating replication of 
previous effort. 

The use of higher-level concepts as basic to the path expression language has the 

disadvantage that properties not closely related to these basic ones can be rather difficult to 

specify. For example, consider the writers' priority database example analyzed in Section 

6.3. There the property was specified by adding to the readers-writers specification above 

the following conjunct, giving priority to operation "write" over "read": 

(write .r«^s» => r eadj• nt • , ) D (write^' =* read^"). 

The'path expression specification for the same example appears in [Cam74] as: 
path readattempt end 
path requestread, { requestwrite } end 
path { open read; read }, write end 
where 

readattempt - begin requestread end 

requestread - begin openread end 

requestwrite = begin write end 

READ •= begin readattempt; read end 

WRITE «= begin requestwrite end 
There is quite a lot of extra effort involved in adding the single property of priority to the 

readers-writers specification, and in terms of comprehensibility it leaves much to be desired. 

Even more discouraging is the fact that giving priority to "read" over "write" is done in a 

slightly different manner. Little wonder, then, that in the next version of path expressions. 

appearing in [Hab75l priority becomes another pre-defined operator in the specification 
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language. ,. /, 

The languages of both this thesis and path expressions claim the virtue of 
extensibility, meaning that further constraints simply can be added onto previous ones 
without changing the existing specification. As the above example illustrates, this is not 
quite true of part* expressions, since the addition- of the, friers' jirior^ty property requires a 
change in the expression of the readers-writers property as mfh, in this Jfhesii, new 
constraints can always be tonjoioed to existing ones. 

The writers' priority database example also illustrates the fact that with path 
expressions new operations sometimes must be invented for the specification of desired 



properties. In this thesis, this is also true, but here 1 it is limited to the single category of 
breaking an operation into serial sections of code in between which the process executing 
the operation may be blocked, as explained in $ection 5Z, W,ith path expressions, blocking 
within operations must be handled in the same 8 **^. fh ffcct " fcfcweW, ir may also be 
necessary to construct a new operation whose only purpose is to call an existing one, such as 
"requestwrite" in the example. Other examples i% ^b^h ja [j^a/B7|^ tJ aj|c| p4ab75] contain 
numerous other such "hidden" operations us%d fn valiai^wlfir III general, a clean 
separation of synchronization code from the data abstraction operations themselves seems 
less feasible with^ path expressions. 
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The final comparison with respect to the specification languages themselves is that 
path expressions contain no facility for expressing properties that involve the parameters of 
operation activations. The only way to handle such properties would appear to be for the 
operation body to call different hidden procedures based on the satisfaction of different 
predicates by the parameters. Path expressions could then express synchronization 
constraints on these hidden procedures. There is no straightforward mechanism, however, 
as there is in the language of the thesis. 

The main thrust of the discussion in this section so far has been that the specification 
language of this thesis is superior, particularly in terms of criteria such as constructability 
and comprehensibility. to the path expression language. With respect to synthesis, however, 
there i& no question that the path expression approach is better. A simple recursive 
algorithm in [Cam74] can automatically implement any constraint specified by path 
expressions in terms of semaphores and integer counters. 

In general, there is a tradeoff between expressive power of a specification language, 
and relative ease of synthesizing implementations from it Because the path expression 
language is designed around a few built-in properties such as mutual exclusion, "canned" 
implementations of these properties can simplify the task of synthesis. The greater 
generality of the language of this thesis results in a far more difficult synthesis problem. It 
is interesting that in later versions of the path expression language ([Hab75], [Flo76]), 
additional features are added to increase the expressive power. These later papers do not 
include automatic implementation algorithms, and the problem of synthesis would appear 
far more difficult for these more complicated versions of the language. 
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8i5 Future work '"*- 

There are a number of areas in which the work of this thesis could be extended in the 
future. Generally, the specification language itseff seems sound as it stands, with the 
possible exception of the inability to refer to the data state of the resource, which is an issue 
that should be investigated. Further work is also needed on using specifications in proving 
properties of data abstractions. 

As noted in Chapter 5, information about the range of values of certain parameters 
would be very helpful in constructing implementations of argument-related properties. An 
automated system could interactively ask for this information from the user. However, it 
could also be supplied as part of the original specification, if the specification language were 
extended to handle it. 

The synthesis method described here can '^ bnly^ : 1»e > ' : '>^e%iiBtf- v iflK ""* ''scirtirig' fidAtt ■ liwr' 

pursuing this general approach. The synthesis algorithm is very complicated, and while 
this is dictated to some extent by the generality of the specification language, the complexity 
almost certainly could be reduced, perhaps dramatically, by looking at alternative strategies. 

One area that could particularly benefit from a different approach is the use of 
qualified gates for argument-related properties. As iftcfiea^^afci^W Section 8.3. the 
implementations resulting from such cases afe uhacceptabiy inefficient. It is unreasonable to 
have to perform a detailed search in determining thr state ^variable to be updated tir the 
condition on which to wait. A change ih the basic solution specification structure would 
probably be necessary to achieve acceptably efffcrent fmptententatiohs Of arg^rrteht-related 
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properties. Unless some alternative were found, it might be better to eliminate 
argument-related predicates from the specification language entirely, even at the cost of 
reducing the power of the language. 

The use of information private to each process; as discussed in Section 4.7, represents 
one possible direction for extending the power of the solution specification. Private 
information would permit each process to look back in the history to a point whose state is 
important only to that process. This would increase the range of applicability of the 
derivation algorithm. Of course, adding this feature to the solution specification requires 
modification of the algorithm so that such information can be derived. This issue would 
have to be investigated. 

An alternative to private information would be a more flexible solution specification 
structure. As noted in Section 8.3, the ability to employ different queuing strategies and to 
have different entry conditions for a gate depending upon context would add expressive 
power to the solution specification. Again, the impact on the derivation algorithm would 
have to be considered. 

Another idea that might bear exploring is the use of more powerful data types than 
simple integers in both the solution specification structure and the source code 
implementation. Specifically, sequences of events may be a more natural concept by which 
to translate properties from history-theoretic to state-theoretic terms. One potential difficulty 
is the fact that there is no theory of sequences as rich as number theory, and no good 
analogue for sequences to the < relation on integers, which is so basic to the synthesis 
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ajgonthm. Also, the problem of sourcerlevel optimizations, which has been addressed 
briefly in the thesis, would become much more serious. 

A limitation of the work here that has been mentioned earlier is its dependence on a 
centralized synchronization mechanism for each data object This jlro^s its applicability in 
situations wbere.data objects may be distributed widely around a system of geographically 
distant processors. It would be interesting to exptor e Jq wha| extent this centralized-conjro] 
bias is built into the underlying model, and see what problems have to be overcome in 
devising an implementation suitable for distributed systems. 

An interesting problem growing out of the approach here is whether or not 
synchronization constraints for an abstract data type can be derived automatically from the 
implementation of the type. Obviously, questions such as whether one operation should 
have priority over another can only be decided by a person, since there is no inherent 
reason to choose one priority scheme oyer another. However, the code implementing the 
operations of a type, possibly augmented by some internal consistency requirement for the 
lower-level representation of objects of the type, can provide enough information to 
determine many classes of synchronization constraints. Which operations must be mutually 
exclusive of each other can often be determined oy analyzing the manipulation of shared 
variables used in the implementation of the type. A number of techniques employed in 
optimizing compilers can also be used: Heuristics such as dead code elimination and 
requiring a variable to be initialized before being used can reveal certain required 
dependencies in the ordering of operations. Success in investigating this area could lead to 
the partial elimination of the need for synchronization code itself. 
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Of all the areas open for future work, however, the most obvious is the need to 
implement in an actual system a method such as the one described in this thesis. Many 
ideas look good on paper, only to founder when actually put into practice. A certain 
amount of system design has been done on paper, in order to help determine the feasibility 
of the system. Nothing has been actually run and tested, however, and only an actual 
implementation ultimately can be convincing as to the feasibility of automatic synthesis of 
synchronization code. 
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